Jump to content
Covecube Inc.


  • Content Count

  • Joined

  • Last visited

  1. @stuart475898, By way of another data point, I am not seeing this on my setup, and I have successfully got Dedupe setup on a volume. Note however that this volume has nothing to do with my Drivepool drives, and I don't use ReFS. This is WS2019 DC fully patched. - TheBigMan
  2. Just want to confirm that the latest beta fully resolves the problem with the Dedupe role on Windows Server 2019. Thanks @Christopher (Drashna)!
  3. This is brilliant... thank you @Christopher (Drashna)!!! Will keep a lookout for the new release once code signing is complete and will try it out. - TheBigMan
  4. Thanks @Christopher (Drashna)! Really appreciate the team looking at this. I have been very impressed with the responsiveness of your team. I saw you have a defect tracking system... is there a bug open for this that I can subscribe to or track so that I can get notified on progress? Does Alex have a rough order of magnitude on getting this fixed (weeks, months, quarters, etc.)? Just trying to set my expectations accordingly. I still have a case open with Microsoft tech support. It's been a frustrating experience as they've essentially been stating that *no* changes were made to the Dedupe role in Server 2019 other than the inclusion of ReFS support. So obviously there were changes. I'm trying to get the dev team to at least be able to explain what they changed in the enumeration code that broke all this, i.e. what they're looking for that breaks your code. Because while I appreciate that ultimately you (Covecube) will need to change your code to adapt to the new environment, Microsoft did not document or even recognize that they'd made a change that would break your product. If you could let me know whether I should continue pursuing this, I'd be most appreciative. My guess is that your dev team know what the issue is, so if I should just drop it with Microsoft, I can do so. BTW - if it helps at all, the *exact* same error occurs with Drive Bender, which is the product I used to use. So Microsoft's change breaks more than Drive Pool. I have been very happy with the move to your product suite! Very well put together and the reliability seems extremely high. And I say that as a storage/data management professional who works for one of the largest storage/data management companies in the industry... Thanks, - TheBigMan
  5. All, Working with Microsoft Support on this too... burned a support incident because I care *that* much :-) I am looking at the Covecube Disk Enumerator in Device Manager; I assume this is the driver referenced in the release notes for the v2.2.3.950 beta. In those notes, it mentions that the driver was updated... see below: --------- * Rebuilt with 17763.134 WDK. Tested and signed for Windows Server 2019. However, the driver I see on my system is dated 9/29/2017 and is version As the version of the WDK mentioned in the release notes was the v1809 build released late in 2018, I am assuming that I don't have the updated driver installed (it's signing date should be late 2018 at the earliest)? My best guess about all this is that the Dedupe service is being a bit stricter in 2019 with it's enumeration of volumes compared with the prior release (2016 a.k.a. 1607), and specifically with the data it's expecting to receive back from the FSCTL_GET_NTFS_VOLUME_DATA call. I am absolutely NOT a developer, so I apologize in advance if I'm misstating something here. The thinking here is that we should start with the Covecube driver updated with the latest WDK, which is what you've already gone and done in the latest beta... but it's not showing up for some reason. Again, any help you can provide is much appreciated. Hoping that @Christopher (Drashna) can assist! Thanks, - TheBigMan
  6. Hi, I recently bought and started using DrivePool on my home media server. I am running a fresh install of Windows Server 2019 Datacenter. Since I installed DrivePool, I am no longer able to use the Deduplication role, as the service won't start. Removing DrivePool and rebooting allows the Deduplication service to start again successfully. To be clear, I am not using Deduplication in conjunction with any drives that are part of my pool, but it is used on another volume to provide massive space savings on File History and even image backups of my PCs. So, not having Deduplication working is a pretty big issue! The Dedupe service seems to be failing with the following information in the Event Log: === Data Deduplication error: Unexpected error. Operation: Starting File Server Deduplication Service. Error-specific details: Error: DeviceIoControl (FSCTL_GET_NTFS_VOLUME_DATA), 0x80070001, Incorrect function. === Has anyone else seen this issue? Could one of the developers let me know if this is a known problem? This does *not* happen on Windows Server 2016, so I assume something has changed in Windows Server 2019 such that the Dedupe service is looking for something from the pool drive that DrivePool isn't responding correctly on. I'm using v BETA as this specifically calls out Windows Server 2019 compatibility. If there's a different version to try, please let me know! Thanks, - TheBigMan Updated 07/05/2019 with specific error information from the Event Log
  • Create New...