DDS and the Application Server

[Sean_Killian]

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?

[Sean_Killian]

After double-checking, I just found this excerpt from the DDS1500 MRG:
"UDP traffic may be blocked between the OnBase Client or application server and the DDS server."
Can I assume that this implies DDS is in fact used on the application server?

[AdamShaneHyland · Accepted solution]

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.