Multi-Site Printing, manage and control all printing in one system

Print management solution for organizations with multiple sites or branch offices.

For organizations and businesses with multiple branches and/or international locations that wish to manage and control all printing in one system, WeP is the best print management solution. While employees in various locations can initiate and collect print jobs, Sentinel secure printing ensures that no one outside the organization has access to them. Multi-site support means that WeP secure printing software is installed in a print server at each site. All sites use a common database and are managed centrally, via the Web. “Distributed installation” allows documents to move from site to site. Most of the print management is handled locally, via the LAN. The WAN is only involved when a user wants to print a document at a different site. Consequently, there is very little WAN overhead or drain on resources. WeP behavior does not change across sites. As a result, users can retrieve print jobs at their current locations, even when they are not in their usual offices, via the automatic “follow me” feature. A user might be in a conference room, on another floor, or visiting another site belonging to the organization. When the user is ready to print a document, s/he can employ her/his mobile device or corporate tag (RFID-enabled or magnetic) to access the Sentinel system. The Sentinel server identifies the user’s location and prints on the spot, even if the job originated at a different site.

Alternate Database

WeP software has on option to keep on working regularly, even when communication between the main common database and a site fails. The site goes on working with an alternate database, e.g., local database. This option is vital for an organization working 24/7. There’s continues synchronization between the common database and the site’s local database. When communication between main common database and the site fails, the local database detects it and starts working. This is because via synchronization all jobs were registered in local database also. When the main common database is up again, all history is updated from local database, and the common database is working normally.