The Document Routing Agent (DRA) should support multiple instances of the service on a single machine, should process multiple jobs (to different printers) in parallel, and should run as a service for precision documents.
These are the current design constraints:
- The DRA currently runs as a Windows service only for documents that do not have custom margins (aka "precision documents") so this means that all precision documents must be printed through a DRA that is running as an application in a user session on a server. If the server ever restarts, a user has to go in and manually start the DRA.
- Also, the DRA processes print jobs, even those to different printers, in serial, causing delays to print jobs at different locations and different printers.
- Additionally, only one instance of the DRA can run on a single server.
The workaround for these constraints is to install a DRA for individual printers or locations on individual servers, and for precision documents, to run them as an application. This is untenable for customers requiring concurrent printing capabilities for precision documents across tens or hundreds of individual locations.
Comments
I've also clicked to vote on this and it also doesn't increase the count. I wonder if this is because it's under review. Most customers prior to go live have mutl
Category: Reporting and Analytics
I click Vote on this item but the number is not updated !
Is this a way for Microsoft to not take into account the need of users to have just a reasonable good software ?...
Category: Reporting and Analytics
Is there any news regarding this much missed feature?
Category: Reporting and Analytics
I want to be clear in my comment: A complete overhaul of the DRA setup needs to occur, ESPECIALLY in the context of security due to the recent vulnerabilities (PrintNightmare). Literally every idea on this site with DRA mentioned should be implemented. The fact that this has been so woefully implemented is an insult to every other cloud-friendly app that MS has published in the last few years, and it only makes it a soft target for large organizations.
1. DRA auto-updating when your environment updates (as many of MS's products can already do).
2. DRA being a multi-threaded service and working with multiple environments in different versions. The connection to that environment can already determine it doesn't match version-wise, why not download the version-specific files needed to run that service so that you can have one app, but multiple revisions running at the same time for multiple services? At the very least, I'd run one DRA server for Prod, and one more for the other 5 environments we have.
3. DRA no longer having reliance on Adobe Reader for precision margins (like for check printing) and instead offering the option to use Chromium Edge's PDF viewer/printing capabilities. Surely command-line printing can be implemented?
4. Removal of the requirement for interactive logons and autologon to maintain an environment's DRA server where you can reboot a server without taking down printing, or requiring someone to manually login.
5. Service mode should not stop PDF submissions to the agent - at the very least there should be the option to maintain a queue when in service mode if you choose.
6. A central web portal that shows all DRA agents configured for all environments and when they last reported in and what errors they're encountering (Similar to ADDS/ADFS/Azure AD Connect health agents). Surely this can be implemented in the same area where all environments are listed. Cleaning up and maintaining this connection to D365 should be paramount for security.
Category: Reporting and Analytics
I agree with all of you. DRA could and must be much better that it is nowadays. I hope as soon as possible.
At the moment I needed to install 3 DRA for just less than 40 printers :-(
Category: Reporting and Analytics
Number 2 and 3 causes issues for us too. Right now we have about 70 printers on 16 warehouses which means 3 servers for stable printing without noticable delays and some redundancy. Soon we will add the stores and service stations to our instance and then we'll have around 300 printers to manage. That'll mean 6 DRA as minimum (if we stay with the recommended max. of 50 printers at one DRA) without redundancy and fallback and about 15-20 DRA servers for a stable and performant system. This is pretty crazy as only 1 print server was sufficient for all printers in our pre D365FO-environment.
Category: Reporting and Analytics
Multiple instance would be the feature we need. We have a customer with many D365 environments.
Now we have to install the Document Routing Agent on 6 or more servers.
Other option instead of running multiple instances, could be:
Create the possibility to connect to more environments from 1 DRA instance
Category: Reporting and Analytics
In addition, the fact that running the DRA as a service cannot be a "set it and forget it" service as the Azure authentication tokens expire at 90 days. Therefore the IT admins need to remember to log into the server hosting the DRA, log out, and log in to the DRA. This makes the DRA a very hand-holding type of tool.
Category: Reporting and Analytics