11-09-2015 11:46 AM
It is my understanding that DDS is not necessary when configuring impersonation on the Application Server, but for a time, we had Client-based services running on our Application Server and had a C:\DDS_ONLY_SERVERS.TXT file there. We have changed DDS servers recently but this file on our Application Server was not updated after doing so (because the Client-based services are no longer running on this server). We have noticed today that certain operations such as adding/deleting pages or scanning from Unity produce an error message similar to:
Failed to verify id file for platter (2) 107:273:1 at: '\\FS:OldServerNameHere:2185:\\OldServerNameHere\path\to\DiskGroup\OnBase.ID'
I have searched for "DDS" within the Application Server 15 MRG and for "AppServer" and "Application Server" within the DDS MRG, but I can find no useful information to determine whether or not the Application Server uses DDS.
Are there any configurations/situations where the Application Server will use DDS?
11-10-2015 05:05 AM
Hi Sean,
Thanks for the post.
When the DDS_ONLY_SERVERS.TXT file is located on a workstation/server running OnBase, upon startup, the application will determine to use DDS for access to the Disk Groups instead of UNC. By default, without the file, OnBase will attempt to access the files of a document via UNC and if that fails it will then use DDS (typically because the user running the application doesn't have access to the Disk Groups). Using the file (or environmental variable) eliminates the UNC attempt and instead goes directly to DDS.
If you have the DDS_ONLY_SERVERS.TXT file on the Application Server, than all access to READ / WRITE / DELECT from the Disk Groups is done by the DDS Server. Typically it is not recommended to have this type of configuration as it is additionally overhead which is not needed when the Application Server is accessing the Disk Groups. In most cases it is recommended to use the Impersonation/Identity account to control access to the Disk Groups from the Application Server for all Core Based Clients (Unity, Web, etc) and DDS for the OnBase Thick Client.
Hope this answers your question. If not, feel free to follow up with more questions.
11-09-2015 11:52 AM
11-10-2015 05:05 AM
Hi Sean,
Thanks for the post.
When the DDS_ONLY_SERVERS.TXT file is located on a workstation/server running OnBase, upon startup, the application will determine to use DDS for access to the Disk Groups instead of UNC. By default, without the file, OnBase will attempt to access the files of a document via UNC and if that fails it will then use DDS (typically because the user running the application doesn't have access to the Disk Groups). Using the file (or environmental variable) eliminates the UNC attempt and instead goes directly to DDS.
If you have the DDS_ONLY_SERVERS.TXT file on the Application Server, than all access to READ / WRITE / DELECT from the Disk Groups is done by the DDS Server. Typically it is not recommended to have this type of configuration as it is additionally overhead which is not needed when the Application Server is accessing the Disk Groups. In most cases it is recommended to use the Impersonation/Identity account to control access to the Disk Groups from the Application Server for all Core Based Clients (Unity, Web, etc) and DDS for the OnBase Thick Client.
Hope this answers your question. If not, feel free to follow up with more questions.
Find what you came for
We want to make your experience in Hyland Connect as valuable as possible, so we put together some helpful links.