[//]: # (werk v2)
# Fix CME specific validations on host and folder actions
key | value
---------- | ---
date | 2024-10-17T05:43:28+00:00
version | 2.4.0b1
class | fix
edition | cme
component | wato
level | 1
compatible | no
CME specific validation to enforce the consistency of customer sites in a folder
hierarchy were not executed properly during the following actions since 2.3.0:
* Create host
* Create subfolder
* Edit folder
* Move host
* Move folder
Those validations ensure that a lower level of the folder hierarchy (host or
folder) can not have a site assigned which is owned by a different customer than
the levels above.
Due to the missing validation in previous 2.3 releases, it might have happened
that unintended configuration changes were made to the configuration. Such
possible inconsistencies need to be cleaned up manually.
Title: agent_cisco_meraki: Apply changes to selected organisations immediately
Class: fix
Compatible: compat
Component: checks
Date: 1725951228
Edition: cre
Level: 1
Version: 2.2.0p34
To avoid too many requests, information about organisations to query for the Cisco Meraki agent are cached.
However, the cache was not invalidated if the selected organisations changed, leading to changes only become visible after the cache interval (1 day).
Now the cache is refreshed when a new selection has been made.
Title: Azure agent: fix query for network interface configuration in virtual machine scale set
Class: fix
Compatible: compat
Component: checks
Date: 1728054182
Edition: cre
Level: 1
Version: 2.2.0p36
When retrieving network interface configuration information for a load balancer,
the agent queried an incorrect API endpoint when handling network configurations
associated with virtual machines, within a Virtual Machine Scale Set.
This resulted in the error: <em>Management client: //aka.ms/ARMResourceNotFoundFix.</em>
Title: azure usage details: increase API page size and specify ClientType
Class: fix
Compatible: compat
Component: checks
Date: 1727687374
Edition: cre
Level: 1
Version: 2.2.0p36
The <code>429 (Too Many Requests)</code> error was frequently raised when monitoring Azure usage details.
This problem was caused by the high number of queries, performed to retrieve the usage details,
due to pagination with a limited number of items per page, and due to the <code>ClientType</code> quota
limit (see: https://learn.microsoft.com/en-us/answers/questions/1340993/exception-429-t…).
This werk increases the number of items retrieved by each individual API call
and specifies a <code>ClientType</code> in the request header.
[//]: # (werk v2)
# agent_cisco_meraki: Apply changes to selected organisations immediately
key | value
---------- | ---
date | 2024-09-10T06:53:48+00:00
version | 2.3.0p19
class | fix
edition | cre
component | checks
level | 1
compatible | yes
To avoid too many requests, information about organisations to query for the Cisco Meraki agent are cached.
However, the cache was not invalidated if the selected organisations changed, leading to changes only become visible after the cache interval (1 day).
Now the cache is refreshed when a new selection has been made.
[//]: # (werk v2)
# Azure agent: fix query for network interface configuration in virtual machine scale set
key | value
---------- | ---
date | 2024-10-04T15:03:02+00:00
version | 2.3.0p19
class | fix
edition | cre
component | checks
level | 1
compatible | yes
When retrieving network interface configuration information for a load balancer,
the agent queried an incorrect API endpoint when handling network configurations
associated with virtual machines, within a Virtual Machine Scale Set.
This resulted in the error: _Management client: //aka.ms/ARMResourceNotFoundFix._
[//]: # (werk v2)
# azure usage details: increase API page size and specify ClientType
key | value
---------- | ---
date | 2024-09-30T09:09:34+00:00
version | 2.3.0p19
class | fix
edition | cre
component | checks
level | 1
compatible | yes
The `429 (Too Many Requests)` error was frequently raised when monitoring Azure usage details.
This problem was caused by the high number of queries, performed to retrieve the usage details,
due to pagination with a limited number of items per page, and due to the `ClientType` quota
limit (see: https://learn.microsoft.com/en-us/answers/questions/1340993/exception-429-t…).
This werk increases the number of items retrieved by each individual API call
and specifies a `ClientType` in the request header.
[//]: # (werk v2)
# Reports are no longer broken if they are generated via a background job
key | value
---------- | ---
date | 2024-10-15T13:55:22+00:00
version | 2.3.0p19
class | fix
edition | cee
component | reporting
level | 1
compatible | yes
[//]: # (werk v2)
# agent_cisco_meraki: Apply changes to selected organisations immediately
key | value
---------- | ---
date | 2024-09-10T06:53:48+00:00
version | 2.4.0b1
class | fix
edition | cre
component | checks
level | 1
compatible | yes
To avoid too many requests, information about organisations to query for the Cisco Meraki agent are cached.
However, the cache was not invalidated if the selected organisations changed, leading to changes only become visible after the cache interval (1 day).
Now the cache is refreshed when a new selection has been made.
[//]: # (werk v2)
# Azure agent: fix query for network interface configuration in virtual machine scale set
key | value
---------- | ---
date | 2024-10-04T15:03:02+00:00
version | 2.4.0b1
class | fix
edition | cre
component | checks
level | 1
compatible | yes
When retrieving network interface configuration information for a load balancer,
the agent queried an incorrect API endpoint when handling network configurations
associated with virtual machines, within a Virtual Machine Scale Set.
This resulted in the error: _Management client: //aka.ms/ARMResourceNotFoundFix._