RJGNOW

So I've gone through, what I believe is, every inch of that manual and these forums and there doesn't appear to be any reason why this would be happening.

Thanks for your response. Each Placement Rule has a least 2 drives selected. I'll take a look at the manual so if my problem is listed.

Thanks for the details response. I'm not using the SSD Optimizer PI, and as you can see in the pic below it's definitely not a physical space issue.

Hello, I'm currently having some file placement issues. Issue: Error in Balancing File Placement tab "12.9 Gigs could not be moved because a suitable destination.." Notes: 1) I have plenty of room on the 2 drives (over 200 gigs) where the rules are applied to (Files amount to ~15 Gigs) 2) The Balancing meter on the main UI window doesn't completely fill and just says "Pool Organization" and when I hover the mouse over the far right icon I get something like the message above 3) The Pool window doesn't displays the little blue box to the right of the drives that you would normally see with this error. 4) All balancer PI's are set to "Default"

Any word on this product's availability?

Found the error, somehow I deleted the "," after the default value in settings. smh....

I've attached my settings.json file zipped Settings.zip

That's the problem, BitLocker_PoolPartUnlockDetect is already set to false.

I have been noticing my drives not spinning down yet again for several months. So I went on the hunt, and again it appears DP is querying all the drives on the system (even those not in the pool) presumably via wmiprvse.exe. As soon as I shut down the DP service it's stops. These are ~4kb hits on all installed drives. So I opened up my setting.json file and to my surprise it was corrupted. (Full of "NULL") So I shut down the DP service, deleted the file, restarted the DP service, it created a good setting file I then shut the service back down, changed the override to false, saved file. rebooted machine. I have confirmed the setting "stuck" but DP continues to hit every disk keeping them all awake. I'm running the latest beta.. Is DP not honoring the setting anymore? Some screen shots https://1drv.ms/u/s!Au3gzKAQDK0wga4NhGO8Tzrz3q5rZw https://1drv.ms/u/s!Au3gzKAQDK0wga4OG6LF_4GlBie86w

I just noticed this myself. When scanner is running, no drive on the system will spin down. Shut the service down and all is good. This use to work, but I'm not sure what version that was, and if it's related to any of the Windows update. One thing I did notice is the scanner appears not to update the power status any more. If I force the drive to spin down with HDDScan, the scanner UI never changes states, same goes for using the internal mech. in scanner to put the drive in standby. The status never changes until you restart the service.

Sorry for the delay, Yes everything seems to be working. Once again thanks for all your help Christopher.

Thanks, I'll check it out.

Turns out it was also Scanner (every 60 seconds). Uninstalled and now the drives go to sleep. What to do next, I'm pretty sure quires were throttled to every 60min..

Hmmmm, Could Scanner be doing this?

Thanks Christopher, that stopped the "every ~5 sec. bursts. Unfortunately still none of the drives will sleep. So looking a little deeper, using process explorer, I see the WMI service accessing all of the drives, (every second or so) but every 60 sec looks like a file operation is conducted (open) on the drives. If I shut down the WMI service, I get a warning that 2 services rely on WMI (ip Helper and some security service) so I shut down those services and problem persists. If I shutdown the WMI service the disk access problem stops. I have stopped every startup program and the problem persists. I suppose I can't just leave WMI disabled. , so do you have any advice on finding what program is using the WMI service to access the drives? PS: From what I've read (for you mostly), the LSI SAS 9207-8i will not allow the drives to sleep by default so I applied the registry hack here. Not sure if it actually works because of the above problem..