I have a working “multiple set” actionscript to set Azure Cloud Plugin settings. I am now adding a 2nd actionscript link that sets the Credentials_ClientSecret value via the “multiple set encrypted” command but it is giving this timestamp error.
Any suggestions?
Command succeeded plugin store "AzureAssetDiscoveryPlugin" multiple set "_my url encoded json_" on "Wed, 21 Jun 2023 16:25:05 +0000" (action:10361)
Command succeeded (Not set as timestamp older than current value, no failure reported) plugin store "AzureAssetDiscoveryPlugin" multiple set encrypted (action:10361)
A setting will not be applied if the timestamp is older than the current timestamp of the setting. I see you’re setting an effective time with a future date, which is probably where the problem lies.
Usually one would use "{parameter "action issue date" of action}" to configure the timestamp as the time the action was issued.
We do this because actions on the client may not be executed in the same order as they were issued on the server, and this timestamp allows us to set the “final” value of the setting as the latest version.
With a native client we could delete the setting from the registry; I’m not sure the equivalent using the cloud plugin I’m afraid.
I am using that within my actionscript:
plugin store "AzureAssetDiscoveryPlugin" multiple set "my url encoded json" on "{{parameter "action issue date" of action}}"
plugin store "AzureAssetDiscoveryPlugin" multiple set encrypted "my url encoded secure json" on "{{parameter "action issue date" of action}}"
Oh, sorry, my mistake, I misread the datestamp in the log as July rather than June. I haven’t had enough coffee yet I suppose.
The message still indicates the current value has a later timestamp. Usually where I see that is when one action sets the value using “action issue date” and another conflicting action uses "{now} to force reapplying an old value.
What if the 2nd plugin store command had 'parameter “action issue date” -1*minute of action" or something?
I pushed the setting via the Cloud Plugin Portal and it ran this. The only difference I can see is my use of “multiple set” / “multiple set encrypted”.
Completed plugin store "AzureAssetDiscoveryPlugin" set "Credentials_Label_{parameter "credentialsLabel"}" value "{parameter "credentialsLabel"}" on "{parameter "action issue date" of action}" for client
Completed plugin store "AzureAssetDiscoveryPlugin" set "Credentials_SubscriptionID_{parameter "credentialsLabel"}" value "{parameter "subscriptionID"}" on "{parameter "action issue date" of action}" for client
Completed plugin store "AzureAssetDiscoveryPlugin" set "Credentials_TenantID_{parameter "credentialsLabel"}" value "{parameter "tenantID"}" on "{parameter "action issue date" of action}" for client
Completed plugin store "AzureAssetDiscoveryPlugin" set "Credentials_ClientID_{parameter "credentialsLabel"}" value "{parameter "clientID"}" on "{parameter "action issue date" of action}" for client
Completed plugin store "AzureAssetDiscoveryPlugin" set encrypted "Credentials_ClientSecret_{parameter "credentialsLabel"}" value "{parameter "clientSecret"}" on "{parameter "action issue date" of action}" for client
Completed notify client ForceRefresh
using actionscript and adding 5 sec like this allowed the timestamp error to go away
plugin store "AzureAssetDiscoveryPlugin" multiple set "my encoded json" on "{{parameter "action issue date" of action}}"
plugin store "AzureAssetDiscoveryPlugin" multiple set encrypted "my encoded encrypted json" on "{{parameter "action issue date" of action as time+5*second}}"
Command succeeded plugin store "AzureAssetDiscoveryPlugin" multiple set "..." on "Wed, 21 Jun 2023 18:57:57 +0000" (action:10368)
Command succeeded plugin store "AzureAssetDiscoveryPlugin" multiple set encrypted (action:10368)
Command succeeded notify client ForceRefresh (action:10368)
Nice sleuthing. I’ll loop in the cloud team and let’s see what they have to say about it. Do you have a case open?
I wonder if the speed of processing is significantly faster on the plugin server than it is on the traditional client.
I’ve reported it internally but I think a case would be useful for tracking if you can spare some time on it.