Bluebeam Revu in a Citrix Environment | Revu 20
This guide contains information for IT Administrators and assumes that the reader has a firm understanding of software installation and Citrix® Administration. Its purpose is to provide guidance when configuring, using, and licensing Bluebeam® Revu® in a Citrix virtual environment.
Further details about Revu installation, configuration, and licensing can be found on the Bluebeam Technical Support site.
Revu 20 is certified Citrix Ready® on Server 2016 R2. See the Revu Citrix Ready page for the full list of certified applications.
In order to stay compliant with our EULA (End User License Agreement), each organization must purchase as many seats as there are Revu users in your organization.
The Revu.exe application is the only part of the Revu suite that is certified for installation in a Citrix environment. Other parts of the Revu suite can be used but aren’t officially supported.
When Revu is used as part of a virtual desktop, all features – such as PDF creation using the Bluebeam PDF printer and application plugins – operate and perform as they would when installed on a physical system. In a published or shared application environment, however, additional steps must be taken to enable and manage processes outside of the Revu application.
Please refer to the Revu Compatibility page for additional hardware and software requirements.
Installation and licensing
Open Licensing is the recommended licensing method for any virtual environment, as it allows for maximum flexibility and access. Perpetual Licenses will also work, though you’ll need to buy as many seats as there are Revu users in your organization to stay compliant with our End User License Agreement.
For more information, see the Revu Licensing Guide.
Open and Enterprise licenses in a VDI environment
When deploying Revu on your system images for persistent and non-persistent VDI, don’t register Revu on the primary or host images. Use Delayed Authorization instead. To do this:
- Install Revu via our MSI package and using the DA=1 option
- Or, Use the Bluebeam Administrator command-line option. See Migrating Multiple Revu Installations to a New License.
Delayed Authorization lets you include the serial number and product key during the installation. However, the registration process is deferred until after the desktops are deployed and a user launches Revu and performs their first save operation. This will ensure each virtual desktop is registered individually.
For non-persistent virtual desktops, Revu must be unregistered on each virtual desktop before it’s destroyed. Failure to unregister Revu will leave the virtual desktop name registered on our license server and thereby occupying a seat on the license. The desktop name would then need to be manually unregistered from our license server (Perpetual) or Revoked from the license gateway (Enterprise).
In the case that an Enterprise License is revoked, the virtual desktop will not ping the license server again, as the seat will be immediately released on Revoke and made available again. In addition, the virtual desktop machine name will remain in the “Pending Revoked” status until the default 15-day offline grace period has expired.
If Revu is registered (Perpetual and Enterprise only) on a system image that is used to deploy persistent and non-persistent virtual desktops, and those desktops receive new machine names, the Revu license will:
- Detect a new machine name
- Unregister Revu on that virtual desktop
- Put Revu on a 15-day trial
Persistent virtual desktops
If you’re planning to install Revu in a persistent virtual desktop environment, you’ll be able to use any of the licensing models and manage the license like you would on a physical machine. A Perpetual license is required to be manually released when the desktop is de-commissioned.
When persistent virtual desktops are created from a system image or template where Revu is already installed, the registration can be pre-configured on the primary using the Delayed Authorization option. This allows you to enter the serial number and product key when Revu is installed on the system image, but the registration isn’t completed until Revu is run for the first time on a newly created desktop.
If you do launch Revu on the system image to test basic functionality before you create any desktops from this system image be sure to reset the Delayed Authorization by using the script outlined on Migrating Multiple Revu Installations to a New License.
Be sure to run the Delayed Authorization script directly on the system image. Failure to do so can cause an issue where an unregistered desktop or system image can cause all desktops and system images to become unregistered.
Non-persistent virtual desktops
Open licenses are ideal for non-persistent set-ups. In these environments, Revu is not registered on the virtual desktop’s system image. Enterprise licenses aren’t a good fit for these environments because a license will only be released once it has been left inactive for 15 days.
With an Open license, Revu will register its license automatically when Revu or a Revu plugin is launched. With a Perpetual license, the license will register when the user saves a document or uses a plugin. In the cases of both Open and Perpetual licenses, only one seat of Revu is registered, so customers must have as many seats on the license as users who will be accessing the shared copy of Revu.
Open licenses are supported in this environment. Perpetual and Enterprise licenses aren’t recommended.
Both Perpetual and Enterprise license models aren’t ideal for this type of environment due to both being node-locked and registered on our licensing server where Revu is only registered once.
All users are using the same seat of Revu, so license owners would need to ensure there are as many seats on the license as there are users who will be accessing, or have the potential to access, the shared copy of Revu.
Managing licenses in a published or shared application environment
When deploying Revu on a Published or Shared server, don’t register Revu on the system image. Instead, use Delayed Authorization for Perpetual and Enterprise Licensing. It’s highly recommended to use Open Licensing for this type of setup. If you create clones or deploy multiple servers from the system image and use Delayed Authorization, you can then register each server except the system image.
With an Enterprise License, Revu takes up one seat for each published or shared application server it’s installed on. If a server with an Enterprise License is inactive for 15 days, the seat will automatically be released from the Citrix environment and made available once again.
If the Server is ever re-imaged, Revu will need to be unregistered first (Perpetual or Enterprise only). Failure to unregister Revu will leave the server name registered on our license server occupying a seat on the license. This server name would then need to be manually unregistered on our license server (Perpetual only) or Revoked from the license gateway (Enterprise only).
With an Open License, Revu is not actually registered on the server; it activates each time a user launches the application. This means that the administrator doesn’t need to audit, restrict the number of authorized users, or manage the registration and un-registration process.
In the case of Enterprise licenses, only one seat of Revu is registered, so customers should ensure there are as many seats on the license as users who access the shared copy of Revu.
Using multiple servers
When Revu is installed on multiple servers, it shouldn’t be registered on each server. It’s best to use Delayed Authorization. If Revu is registered on a system image and the registered server is then cloned or deployed, this links the licenses of the system image with its clones. Therefore, if one server is unregistered or revoked, that change is applied to all servers. This will cause all users to lose access to a registered copy of Revu.
To prevent system images from being registered, you can:
- Install Revu as a trial.
- Omit the serial number and product key if you’re deploying Revu using the MSI.
- Register Revu after cloning or deploying with a Bluebeam Administrator command-line option. For details, see Migrating Multiple Revu Installations to a New License.
- Include the “DA” delayed authorization option if installing using the MSI. This lets you include the serial number and product key during the installation. However, the registration process is deferred until the first time Revu requires a license.
If Revu is registered and a Server is cloned and given a new machine name, Revu will detect the machine name has changed and unregister itself and put the license in a 15-day trial period.
Frequent Server Reimaging
If the Citrix server is frequently reimaged, using an Open license is highly recommended. Open licenses won’t cause any license management issues like Perpetual and Enterprise license models.
Restricting Access to View Mode Only
You can allow groups of users to use Revu in either View and or Markup Modes. This setting can be useful if you want to restrict a group of users to View Mode so they don’t consume a Revu license. This method is compatible with the Open license model.
The below registry key is not part of the default Revu installation, but you can write a separate script or Group Policy to push this key per-user as they log into the server to access Revu. This key is per-user under HKEY_CURRENT_USER.
Create a new registry key of type DWORD in:
Set the value to an integer value of 1 and Revu will start in View Mode. The option to switch to Markup Mode is hidden, as well as the option to register/unregister. To allow the user to switch to Markup Mode, either delete the registry key or set the value to 0.
Files and Folders used by Revu
All folders where Revu installs its files are fixed; the Suite installer doesn’t allow the install destination to change.
Revu installs to the followings folders:
- Program Files\Bluebeam Software\Bluebeam Revu\20\
- Program Files (x86) \Bluebeam Software\Bluebeam Revu\20\
- Program Files\Common Files\Bluebeam Software\20\
- Program Files (x86)\Bluebeam Software\Bluebeam Revu\20\
- ProgramData\Bluebeam Software\Bluebeam Revu\20\
On a physical machine, Revu saves files in several locations that store customizations to the Revu interface, custom tools, and cached files to improve performance and reduce internet bandwidth. Studio Projects store the work-in-progress of checked-out files.
In a Citrix environment, these settings should be stored in a user’s folder on the server to provide a persistent environment for the user. This will help prevent any work or settings from being lost.
User Settings & Preferences
Profiles provide an easy way to store a user’s favorite toolbars, menus, and other display settings within Revu. Default and custom tool sets store your most frequently used tools and symbols for easy access.
Profiles, configuration files, and the “Recents” list are stored in the following folder(s):
C:\Users\<User Name>\AppData\Roaming\Bluebeam Software\Revu\20\
Custom tool sets for your environment can also be stored in a central location so they can be accessed by all users. See Using Shared Profiles on a Network Location in the Revu Administrator’s Guide for more information.
Resetting the Revu settings
Revu settings can be reset to their defaults. After resetting, Revu will restore its default profiles and tool sets the next time it starts.
In a virtual desktop, users’ settings can be returned to the default using the Admin tab in Bluebeam’s Preferences.
In a virtual app environment, deleting or renaming the following folder will reset Revu settings:
%AppData%\ Bluebeam Software\Revu
Custom tool sets and profiles can be backed up by copying them before they’re deleted. For other methods in restoring Revu to its default settings, see the Bluebeam Administrator’s Guide.
Log and Temporary Files
Revu log and temporary files are written to a folder in the following TEMP folder(s):
Exporting from Revu to external formats, like Word and Excel, writes temporary files to:
Revu stores recovery files in the following folder:
Files in this folder allow unsaved work to be recovered if Revu closes unexpectedly. This folder should be maintained in the user’s folder on the server to enable crash recovery.
Sets Cached Files
Revu creates cached files for Sets thumbnails in the following folder:
These files are required to build the Thumbnails for Sets. To learn more about Revu’s Sets functionality, Working with Sets.
Bluebeam Studio File Caching
Studio Sessions and Projects store files in the following folder:
Example: C:\Users\<user name>\AppData\Local\Revu\
Revu saves network bandwidth and lets users work offline by storing copies of Project and Session files locally. These files need to be stored in a persistent location in the user’s environment so that they remain accessible between Revu sessions.
Sessions store pending updates for offline files. The markup information is then uploaded to Studio the next time the user goes online. Projects store locally-saved changes for checked-out files, which are uploaded to Studio when the server copy is updated.
To learn more about Studio offline functionality, see Working with Files in Studio Offline.
By default, Revu 20 installs with its Rendering Engine mode set to Hardware. GPU hardware must be present on the server to utilize the Hardware Rendering mode. If Hardware is selected, but there is no GPU to use, Revu will give the following error when trying to render a PDF:
After selecting OK in the error above, Revu will set the Rendering Engine mode to Software.
Unless this Hardware setting is changed on the Citrix server, XenApp users may experience the above error message whenever they open a file on their instance of Revu. XenDesktop users may only see the message once because the Rendering Engine preference will be saved in the user’s Revu settings.
If you want to set the default Rendering Engine to Software, refer to the Deployment Guide for details on pushing out Revu Preferences.
Users can also change the Rendering Engine mode themselves via Revu’s Preferences. The Rendering Engine will need to be changed for both 2D Rendering and 3D Rendering.
To do this:
- In Revu, click Revu > Preferences (Ctrl+K).
- Click Advanced on the left. Click on the 2D Rendering tab.
- Select desired engine in the Rendering Engine drop-down menu and click OK.
- Click on the 3D Rendering tab.
- Select desired engine in the Rendering Engine drop-down menu and click OK.
Using the Bluebeam PDF printer and plugins
The Bluebeam PDF printer and plugins for Microsoft® Office® can be used to create PDF files.
The Bluebeam PDF printer and plugins create temporary files during the creation process. The user must have permissions to the following locations so PDFs can be created.
Bluebeam PDF printer:
%AllUsersProfile%\ Bluebeam Software\Print Jobs\
C:\Users\All Users\Bluebeam Software\Print Jobs\
When running Revu as part of a published desktop, all features – such as PDF creation and application plugins – operate and behave in the same way as when installed on a physical system.
When running in a Citrix-published application environment, the Revu application (Revu.exe) is the only application in the Revu suite that is certified. Additional steps need to be taken to enable and manage processes outside of the Revu application, such as PDF creation via the Bluebeam PDF printer and plugins for Microsoft Office.
Plugins for Microsoft Office
The plugins for Word, Excel, PowerPoint, and Outlook can be used in a published app environment if Office and Revu are both installed on the same server. However, as stated above, these extensions are not officially supported.
Enabling the PDF Printer
The Bluebeam PDF printer and some versions of the plugins for Microsoft Office (see above) rely on the Print Monitor (BBPrint.exe), which is a separate application that runs in the background when Revu is installed on a desktop system. In a published app environment, the BBPrint.exe application must be running and available to the application using the printer or plugin.
An instance of BBPrint can be started in one of the following ways:
Starting BBPrint with the published application
One way is to start this process with a script when a user launches a published application. For example, point the command line for the published application (in this example, PowerPoint) to a .bat file containing commands to launch BBPrint.exe and the application.
Below are examples that show starting different versions of PowerPoint with BBPrint.exe:
Revu 20 and PowerPoint 2016:
start "PrintMon" "C:\Program Files\Bluebeam Software\Bluebeam Revu\20\Revu \BBPrint.exe"
start "PowerPoint" "C:\Program Files\Microsoft Office\Office16\PowerPnt.exe"
Starting BBPrint in a Login Script
Another option is to start BBPrint.exe as part of a user’s login script so that BBPrint, the Bluebeam PDF printer, and any plugins are always available.
Because there are numerous ways to configure and manage a server, there is no single way that will work for every use case. These suggestions are meant to educate server administrators about how the printer and plugins work so you can implement the best solution for your environment.
Disabling Plugins for Microsoft Office for Non-Bluebeam Users
If there are Citrix users that should have access to Microsoft Office, but not have access to these Revu plugins, they can be disabled globally for those users to prevent them from loading the plugins. Blocking a user’s read access to the following registry keys will stop the plugins from loading.
Office 32-bit and 64-bit
RDP (Remote Desktop Protocol) and other virtual environments
Renaming the default Bluebeam PDF printer name under the Printers & Scanners menu (Windows) is not supported. If the name is edited, and a user attempts to print, Revu won’t be able to find the printer. The Bluebeam PDF printer will then attempt to reinstall, and the printer name will be reverted to its default.
In the case of an RDP Session, it’s best to use the default Printer Redirection if the user needs to select between printing directly on the RDP Session machine or their local/host machine.