Hello Internet
From time to time i have a strange issue with PU
IT looks like some of extended attributes are not populating when fetching them with PU
And its not the same for all kind of objects.
Right now when im fetching AD users - EmailAddress propriety is not populated (but mail is), and the other that I use also are populated (like locked, expired, changed password etc)
And for computer objects when fetching LastLogonDate, OperatingSystem, whenChanged, Description attributes - only Description is populated to variable.
Strange it was working fine yesterday and before, then i started to mess up with caching this and from this time everything broke.
I disabled it from cache scripts restarted PU several times but issue still exists
I had something like this before (for users) and i don’t know exactly why ive done to solve it (or maybe it started to working miraculously)
There are no error in the logs, no memory leaking, nothing.
Just empty properties in the variable.
Im sure its only connected to PU itself, on any other server or user that is executing such task everything is ok so its not problem with AD.
Any way to narrow down the problem or potentially fix it ?
ok. i was able to actually fix it
previously i just commented the line when this cache variable was assigned
then restarted PU server few times. i thought that this will clear are cache scopes.
but its not true, i ve checked that it still exists.
so i assigned null value to this cache scope and run script again.
and voila are fields are populated (for both computers and users )
so i have 2 questions:
cache variables are in database ? they are persistent ?
its seems like when i was populating this cache variable for computers (which is quite big, few thousand of computers with extended attributes) it some how reached its limit for all cache variables (i cache a lot of them mainly for users). so how big this cache limit is and how to maybe increase this limit ?
1 - If you use the -Persist flag on Set-PSUCache, it will store it in the database. If you don’t use -Persist, it stores it in memory on the server it was called on.
2 - There shouldn’t be a limit on the cache (that I’m aware of) but I would likely need to understand what magnitude of items are being stored. MBs\GBs?
I also cache ‘real’ and tech users similar way (to few cache variables)
I have a script that is called every hour and is updating those cache variables
So with few thousands objects cached it was ok but if i add twice as many there is a problem
I also noticed that reading ad computers is demanding task. With those 4 extended attributes updating variable takes from 6 to 12 sec.
But if i added one more (ip address), it could take as long as even 30 sec to update.
And if i have to do it every time the page is loading it takes too much time.
Thats way i tried to add this to cache but it didnt work either.
I will try to do it tomorrow on my dev machine with PU 5.2.
Maybe results will be better.
The $Cache scope just uses an in-memory ConcurrentDictionary so it won’t survive restarts of the process. There should be no limit on the size and it shouldn’t be persistent at all.
I was not able to replicate persistence of cache scope on dev machine.
After restart variable was gone.
But main problem still remain - only default properties are being fetched.
This line in App works (extended attributes are fetched)
PS.next update
Its not matter of how many there are objects (even when im scanning OU with 3 computers it does not work)
Its not matter of $cache scope as it is (when $cache:ad_computers is assigned in App - it works )
Its a matter of not working in scheduled script (no matter whenever its running on schedule or manually of course)
