Our support team at DocuWare takes great pride in providing excellent service to our customers and business partners. Our support teams are there to help with technical challenges arising from normal product usage; however, from time to time, we get support requests that fall outside of our scope of service.

To improve the implementation and success of your projects and thus your planning reliability, we have compiled some use cases which are not addressable by our Support Team. In some cases, these tasks can be performed for a fee; please get in touch with your sales representative for more information. We ask for your understanding that we have to exclude support from our support team for the mentioned use cases.


Use Case Title
Can be ordered
for a fee

(contact your sales representative)

Moving a DocuWare System/Services to another Server
Moving a DocuWare system is a complex process that can be even more difficult in different constellations of databases, operating systems and DocuWare versions. This process requires a deep technical understanding of DocuWare. Our experience has shown that problems can be caused by errors or inaccuracies during the execution of this process. The move of a DocuWare system to a new server or the move of components of a DocuWare system, as well as problems resulting from the move of the system from one server to another, are therefore not part of our Support Services.

Problems caused by hardware or software specifications which do not meet DocuWare system requirements for client and server machines.
Unfortunately, we cannot support systems that do not meet DocuWare's minimum system requirements, for example, Microsoft SQL Server Express, Self-hosted Cloud environments or Systems that do not follow DocuWare's System Architecture Whitepaper.

All triggers which are not created by DocuWare Setup in all DocuWare databases.
Triggers can lead to unexpected side-effects like database deadlocks. This can lead to various errors within DocuWare. Often editing or storing documents is affected. We require exclusive access to all DocuWare databases.

The customer wants to make his Web Client reachable from outside the company network.
Starting with DocuWare 6.7, the web components connect directly to the database server. Therefore, installing DocuWare web components in a DMZ is not recommended and supported. The web components should be installed within the LAN only. The web server in the DMZ acts as a reverse proxy then. All requests will be redirected to the appropriate internal web server, e.g. via ARR (Application Request Routing). You'll find a description of how to setup up a web server as a reverse proxy with ARR here: http://www.iis.net/learn/extensions/url-rewrite-module/reverse-proxy-with-url-rewrite-v2-and-application-request-routing
In the "Configuring Rules for the Reverse Proxy" section, you need to redirect all requests to http://.../DocuWare/ to your internal DocuWare web server. Only the URL from the reverse proxy should be published to the WWW; this configuration is done directly in the IIS.

Request for a custom tool/program fitted to the customer's needs or support for this tool
Due to a company policy, custom programmings can not be offered or supported by DocuWare Support or Professional Service. You may ask your sales representative at your DocuWare Partner.
Partner only

Issues caused by multiple or cloned DocuWare systems in the same subnet
Since the Microsoft Messaging Queue (MSMQ) communicates via multicast, we cannot support multiple systems on the same network. The communication of the MSMQ with other systems interferes with each other. Since the MSMQ communicates via multicast, requests are exchanged between the systems, which can lead to significant interference. This can have severe side effects on AutoIndex or Workflow Manager Workflows or settings cannot be passed to the frontend. We can adapt the configuration of the MSMQ Multicast address and test if interference is solved.
Cloned or copied systems automatically adapt the settings and configurations of the host system. In this case, the database GUIDs and configurations are identical. The dependencies of the productive system are mirrored, which can cause severe issues on the cloned or even host system if the configurations are not separated and adapted to only use its local settings.

Issues caused by DocuWare System, which is installed on a database server with database/server collation other than the supported ones.
Unfortunately, we can't support collations or language schemes other than DocuWare's supported collation. Supported schemes and collations are listed in the system requirements. Installing DocuWare with a not supported collation can cause issues with storing index values and can render the system unusable after installation. We recommend reinstalling the existing DocuWare system on a supported collation or language scheme.
Case-by-case decision

It can happen that the DocuWare Web Client/ DocuWare Desktop Apps are not working because of an active proxy/anti-virus in the customer's system. How to check if there is an active proxy/antivirus configuration in the customer's system: https://support.docuware.com/en-US/knowledgebase/article/KBA-35507
The reason is most likely that the user does not use the correct proxy configuration, or the proxy blocks the user's requests. To be sure that the behaviour is caused by a customer's proxy or antivirus software, the system has to be checked first - this is part of DocuWare Support. But we can't offer support for the configuration/adaption of the proxy or antivirus; we can advise what changes must be done by the customer's system administrator.

The customer wants to use HTTPS communication protocol to open the Web Client instead of HTTP.
DocuWare is shipped using HTTP by default. We cannot ship valid SSL certificates as it is in every customer's hands to acquire a valid certificate that is only usable for their server/domain name. Furthermore, the configuration is done in the IIS itself. General IIS Manager: How to prepare IIS to work with SSL certificates http://technet.microsoft.com/en-us/library/cc754841.aspx Adaptions in DocuWare: Change the URL in the Web Connection section in DocuWare Administration - Internal address and HTTP-Root directory If HTTP is not possible in general, change the "LocalWebServices" address in the file "C:\ProgramData\DocuWare\ServerConfig\dwmachine.config"

Uninstalling or deleting any part of DocuWare with a registry cleaner or deleting content from the installer folder of DocuWare will result in errors/issues during the DocuWare server/client setup.
Using third-party tools will result in partly uninstalled components and takes a lot of time to fix, if it is possible to fix them at all. We can only provide support if DocuWare was uninstalled via the official way.

Analysis and troubleshooting of Workflow Manager Workflows.
Understanding the customer's requirements and the individual logic workflow configuration requires additional time and effort, especially if the behaviour is caused by the logic and design of the process and the workflow's configuration. If your request is due to an inherent software problem, it is covered by your existing support agreement. A software problem must be concluded via an independent test system and confirmed by DocuWare’s Product Management.

Typical database maintenance requests like creating database indexes, maintenance plans, identifying fragmentation or modelling data structures.
Maintaining and servicing databases (MySQL, Microsoft SQL, Oracle) is a complex and very time-consuming task that should be carried out by database experts only. Our experience has shown that if the care and maintenance of the database were not carried out, this subsequently led to performance problems in the individual DocuWare systems. Defragmenting indexes, as well as maintaining and recreating required indexes, is a critical and challenging task that requires deep database knowledge of a trained DocuWare technician as well as a lot of time and preparation. Please see our official knowledge base article with further recommendations for database maintenance.
Case-by-case decision

No DocuWare databases backups / No backup plan existing.
Some behaviours and issues can be solved by restoring a database backup only. This requires a solid and well-thought-out backup plan. This has to be set up and provided by the DocuWare Partner or customer IT itself. DocuWare Support is not responsible for managing databases, their maintenance or the setup of backup plans. If no database backup is available, support will be limited, and it cannot be guaranteed that the issue can be solved.

Problems caused by external Applications using Webhooks
DocuWare WebHooks enables you to send data to any 3rd Party application. Suppose there are changes in the API data contract (Documentation that describes how the API works and how it should be used) of the third-party application. In that case, DocuWare WebHooks have to be adapted manually. DocuWare is not responsible for verifying if the API data contract used in the customer's WebHook is valid. Therefore, if you are calling a third-party application, you must make sure you are using a compatible API data contract at any time. DocuWare is not accountable for issues caused by the change of a third-party API data contract, and problems caused by those changes can not be processed via DocuWare Support.

DocuWare On-premises customers have to implement a maintenance plan in their DocuWare database (MySQL, MSSQL, ORACLE) to automatically clear / reduce the size of data within _AUD tables
This procedure cannot be implemented in DocuWare and has to be maintained on database level. We cannot decide how long the Audit should be stored for the specific use-case. (Regulatory restrictions) The customer / partner / database provider has to create a plan / schedule to keep the _AUD tables “tidy”. As an intermediate solution, a backup the database can be taken, and entries from database can be cleared like described in this Knowledge Base Article.
Partner only