Craig Williams President/ CEO

joe
The method that supported the Stapling of Documents in this way does not exist in 7.9 
Clients are having to remove documents and staple then OUTSIDE of Docuware to accomplish this
It should be a part of the FileCabinet Class Method and it is missing. 
Can you assist. 
 

DW7.9 requires SMB3 connections for storage and some of my storage NAS supports SMB1-3 at the same time and it seems if I use AD/SAMBA together DocuWare has trouble connecting.  Storage says it has wrong name and password and can't login. 

I can log onto that same machine as the Docuware Service user and connect to storage without an issue. 

It does use that space if I allow 'all guests' onto the storage but I would like to manage that space.  Any ideas?

i am not certain if DW is checking to see if SMB 1 is supported and does not want to use the connection but I like it is a different issue altogether.  Setting DW7.9 has been pretty easy to deal with so far and once it is running, has been quick and seems very stable. I have been manipulating it thru code and it responds very quickly. 

Any insight appreciated.

 

Awesome thank you!

Good to note, looking forward to the change

I have a client that has Intelligent Indexing that does NOT want to put up a Hyper V server in their farm.  
They do however have a contract with Microsoft on Azure.  The client is concerned with the intensity of the disk activity by Intelligent Indexing as they are counting every 500,000,000ths of a penny. 

HIs concern (quote)"
microsoft charges for storage transactions on top of everything else, and while it's not expensive: $.0020 per million transactions, I can imagine some applications out there would run up the bill. 

https://azure.microsoft.com/en-us/pricing/details/managed-disks/
"Any type of operation against the storage is counted as a transaction"

any estimates you can provide, ballpark or otherwise, would really help."

I have no idea how intensive Intelligent Indexing 2 is.  
Any help appreciated. 

Craig

 

I have been told to "Turn off the Volume limits" 
Docuware 7.x does not support auto volume switching or sizing.....

It is annoying that we take steps forward and backward at the same time.
With the volumes being separated it was very fast and very easy to backup volumes of data. 
We instruct our users to back up the COMPLETE volumes with a keep forever status in backup system.  
Once that is done there is very little reason to parse thru those directories every single day.

You can decide how to manage records on those volumes that get updated.  I have built reports for clients that show which volumes have records that have been modified over the MONTH/QUATER/YEAR and they go back and recreate backups for those volumes and then take them off the daily/weekly routines.
  
For the most part larger clients do not have large deposits of active records,  I would say that less than one half of any repository is active and the rest is library, stored and kept for everyone's reference. I understand the focus on front end and saving time but the backend is important as well. Managing storage is critical when you consider large repositories. 

I have clients will eighty million or more pages in Docuware.  There is no reason to review and backup 80,000,000 pages every day/week/month etc unless they really have changed.  There are products that will help with this. Double Take was one that we used for a while. I have seen clients use snapshot and LUN backups and learning to manage those is different but very effective once it is in place and watched over.  
Good luck!
 

The complete error is 403 Forbidden (Operation can not be finished because your quota limit has been reached.)

My client has a large system with over 2400 volumes of images. 
We started to get the error "Exceeded quota" when storing to the system . 

A call to tech support had the client turn off the volume limits and it is now storing. 
Tech told them this was a well known issue but I could not find a single reference to it .   

So what is the issue? How do we fix it?
They want to use volumes for easier backup management so how do we get back to the way it has worked?
 

I had this same issue and reviewed the records in the table and found a large number of them were not associated to Filecabinet GUIDS that existed. I am not certain but this seems to cause some issues with the way the tasks are removed from the table. I did a search of all the GUIDS in the settings and found the Task_Type 0 records that existed and deleted them. Once I did this the table started to shrink immediately. I did find you cannot remove the Task_Type=2 records as they are locked.  I have noticed that this also causes an issue with Backups.  All of the Docuware Backups I have failed with an error calling out the DWTask table. 
1) Exception Information

     Exception Type: DocuWare.Common.Exceptions.DWException
    MachineName: IL084PDW2
    CreatedDateTime: 11/12/2020 10:02:10 AM
    AppDomainName: DWAuthenticationServer.exe
    ThreadIdentityName: 
    DWUserLogLevel: Unknown
    TranslatedMessage: General error while reading data from table DWTasks
    Message: General error while reading data from table DWTasks
    TargetSite: Error accessing exception member - Exception has been thrown by the target of an invocation.
    HResult: -2146232832
There are currently over 6 million items in this table.  

I am hopeful reducing the number of records in this table will allow the backups to function or at very least help me to find the issues that still exist. 
  

Pay attention to the server types and the versions. Depending on which version you are moving from/to the type you are currently on may not support the new server version.... Example 51b wont run on 2012 server....etc