epa80's Accepted Solutions

Turns out our issue was actually an exception for an app we were unaware of. After digging in the logs with Trend Micro, we were seeing a log file getting scanned constantly. Put in an exception, and, well, you can see the difference.

If by chance anyone sees this issue again, we found the culprit. Can't explain why, but, we found it. It turns out we needed to exclude the file C:\Windows\ntbtlog.txt from being scanned by Deep Security. If we do that, on refresh, the VMs don't seem to get the random issue of some sort of network blip, that resulted in the initial pull down of GPOs to fail. I can't find a single KB/best practice guide stating anything about this file at all, let alone for exclusion reasons. If someone is aware of what kind of relationship ntbtlog.txt has to the Refresh process, I'd love to hear about it. Again, on a full recompose/deployment of a full, the issue never happened. Upon refresh, about 1 in 4 or 5 VMs would experience it. Once we excluded the file from being scanned, we are able to refresh over and over without the issue. Thanks.

We were experiencing high CPU in the vCenter where the bottlenecking was occurring. The vmware-invsvc was through the roof, and it turned out the cause was the root file system was running out of free space due to excessive logging in audit.log. This KB was related to it some. vCenter Appliance root Partition 100% full due to Audit.log files not being rotated (2149278) | VMware KB