The PendingFileRenameOperations value is a REG_MULTI_SZ type. There should be multiple “lines” to this value when you read it in regedit. The lines are in pairs - where the first line in each pair is the source file, and the second line of each pair is the destination file. An empty second line implies a Delete rather than a Move. As an example, right now my workstation has these values:
In this case, “C:\windows\system32\spool\PRTPROCS\x64\2_GNUD054C.DLL” is set to be deleted on the next reboot, “C:\windows\system32\SET54BA.tmp” is going to be moved to “C:\windows\system32\difxapi.dll”, “C:\windows\system32\spool\PRTPROCS\x64\2_hpcpp107.dll” is going to be deleted, and “C:\windows\system32\spool\DRIVERS\x64\3\New\hpcpu107.CFG” is going to be moved to “C:\windows\system32\spool\DRIVERS\x64\3\hpcpu107.CFG”. These files are all related to a printer, so it looks like I’ve loaded a new print driver since I last rebooted, and some printer driver moves are going to occur on the next boot.
What you’ll need to do depends on the values in this key. One possibility is that you just need another reboot to make the file moves occur, this registry path will get cleared, BigFix will detect there are no more Pending Reboots, and your action statuses will update. Probably not likely, since that hasn’t happened yet.
There are several known software packages that incorrectly use PendingFileRenameOperations as a counter or self-repair of sorts, adding values every time the system reboots. If you find that you have some software behaving that way, the best answer is to contact the vendor to have them stop using this value incorrectly. That’s probably not very practical, so BigFix provides a way to ignore particular strings in the PendingFileRenameOperations value. See http://www-01.ibm.com/support/docview.wss?uid=swg21506002 for an explanation of how to use the
_BESClient_ActionManager_PendingRestartExclusions client setting.