cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Agent : User Access Logging export takes 3 hours on front servers with SharePoint

Hello,

We've thousands of inventory agents (v15) deployed across the organization including PCs and servers. We never had any issues with it until the begging of this year when the front end servers of our production SharePoint environment experienced severe lags every day. After investigation, it appears that a PowerShell script is the cause of a jump of memory usage during the inventory (scheduled during business hours). A snapshot of the scripts shows that it's related to UAL queries (Get-UalOverview -> loop Get-UalDailyAcces).
In the tracker.log of the affected servers, we can see that the Powershell execution routine takes about 3 hours to process :

[28.01.2024 12:11:38 (G, 0)] {28508} Powershell execution routine
[28.01.2024 15:31:26 (G, 0)] {28508} Started tracking packages

Wheras it took several seconds weeks ago on the same server with about the same number of users/queries.
UAL, that is enabled by default, had to be disabled on those machines to workaround the issue.

Any advice..

Thanks !

Jérémie

(1) Reply
ChrisG
By Community Manager Community Manager
Community Manager

I haven't come across situations where this particular step of the inventory gathering process has been reported as causing problems like you're describing. But for troubleshooting purposes, you could try running the following PowerShell statement to see how long it takes and whether it produces an unusually large amount of output in the RawUalData.txt file:

Get-UalOverview |
select ProductName, RoleName -Unique |
%{ Get-UalDailyAccess -ProductName $_.ProductName -RoleName $_.RoleName } >RawUalData.txt

This statement queries similar raw user access data to what the script you have referred to is processing.

(Did my reply solve the question? Click "ACCEPT AS SOLUTION" to help others find answers faster. Liked something? Click "KUDO". Anything expressed here is my own view and not necessarily that of my employer, Flexera.)