Skip to main content

In Exchange Online backups there is a job that runs daily called a “live update”. This job is small in size (only a few KB) but it attempts to write to the library directly from the Index Server associated with the Exchange Online Client.

In my environment the Cloud Storage library is restricted to specific VNET’s for security. This VNET contains the Access Nodes and MediaAgents as we use Cloud Storage Accelerator to process the backups.

When the VNET restriction is in place this job fails as the Index Server which is not in the same VNET is unable to access the cloud library. If I remove the VNET restriction on the storage account the job runs without error.

Is there a way to find out where this job is initiated from so it can be massaged to write to storage via the MediaAgent rather than directly?

Hello @Michael Woodward 

The Live update job you are seeing is the trueup process, to remove items that have met retention from the index.

https://documentation.commvault.com/commvault/v11_sp20/article?p=28891.htm

This process is required to run on the index server. We could discuss the possibly of a CMR for this so that it does not write directly to the library itself. Currently I do not think there is a way to change the behavior.


Hello @Michael Woodward 

The Live update job you are seeing is the trueup process, to remove items that have met retention from the index.

https://documentation.commvault.com/commvault/v11_sp20/article?p=28891.htm

This process is required to run on the index server. We could discuss the possibly of a CMR for this so that it does not write directly to the library itself. Currently I do not think there is a way to change the behavior.

Thanks @Scott Reynolds for the explanation. I’ll look to move my index server to the correct VNET or allow an additional VNET access to the storage account.

I certainly couldn’t find a way to change the behavior.

Michael


Reply