Best Practices for Planning a Reflection Deployment
Follow these best practices to avoid common problems and make sure your deployment meets customer and technical requirements without disrupting users.
1. Identify Technical and User Requirements, Subject Matter Resources, and Risk Mitigation
Large-scale terminal emulation deployments have significant risks in terms of delays, cost, and user acceptance. Performing a high level assessment allows you to identify risks at an early stage, and plan mitigation strategies to address them. Be sure to:
|Develop communication plans Develop plans to communicate with user groups and key personnel throughout the process to avoid the communication problems that are common to many deployments. User organizations may not be aware of their licensing options, when they have to upgrade, or which resources and information to provide. IT staff are sometimes unaware of desktop macros and other customization files that are required for user groups.
|Coordinate to make sure all stakeholder needs are met Make certain all user groups, IT, and stakeholders are "on the same page" and are prepared regarding what is needed, schedules, and expectations.
|Define high level requirements Define high level requirements by collecting and analyzing all the information required to define and prioritize needs, address user concerns, and improve user acceptance.
|Define resource requirements Define resource requirements to determine how many and what type of resources your deployment requires.
|Assess customization requirements Assess your current environment to determine which customizations are required for user acceptance. Be sure to address special security requirements or other needs such as file transfer.
|Assess risks Assess the risks of application compatibility and user acceptance.
|Perform a high level analysis of your solution Make sure your deployment solution complies with new security mandates, reduces maintenance, meets productivity requirements and still has good user acceptance.
2. Inventory and Analyze User Requirements, Macros, Configuration Files, and Legacy Applications
Conduct a detailed inventory for each user group to determine which user applications and configurations are critical, used, or not used and whether your terminal emulator requires integration with custom applications. Performing an inventory of your current emulation collateral provides the data you need to make sound technical and business decisions about what to carry forward. It also helps identify needs for customization of Reflection and for integration with other applications. Be sure to:
|Define user requirements Define user requirements for each user group to determine the priorities for this group and special needs such as file transfer capability or security requirements.
|Inventory User Desktops Inventory desktops to assess how many vendor products and files are being used in the existing configuration.
|Identify integration needs Identify needs for integration with HLLAPI or other applications that use your terminal emulation software.
3. Assess Which Existing Files To Carry Forward and Test
The success of your deployment depends on careful assessment and planning. After you determine which files to carry forward, you'll need to convert them to Reflection Desktop files and then test these new files.
|Assess which existing files are required Assess which macros and configuration files are required for your new solution.
|Analyze inventory data Analyze your inventory data to make key technical and business decisions about what to carry forward and deploy.
|Convert Reflection 14 or Extra! files to Reflection Desktop files If you plan to carry forward any existing files, open the files in Reflection Desktop and save them (and any related supporting files) as Reflection Desktop files. If any of your Reflection 14 or Extra! session files have macros that are locked and password-protected, these macros are lost when you open those files in Reflection Desktop. To import the macros, you'll need to unlock the macro projects before you open the files. Note: Reflection Desktop cannot import Extra! or legacy Reflection macros when they are locked because it needs to access the macro projects to convert them.
|Test all files in Reflection Desktop Make sure that the macros, configurations, and other files work with Reflection Desktop.
4. Package and Test
Package, test, and deploy to selective user groups and conduct pilots to minimize user disruption. Be sure to test for both technical issues and user acceptance.
Use this checklist to avoid common problems with Reflection deployments.
|Deploy files to trusted locations. The Trusted Locations feature provides a way to differentiate safe files from potentially harmful files. When a file is in a trusted location, itRSQUOs files are assumed to be safe. Reflection enforces trusted locations by default, so if you want to save sessions in directories that are not default trusted locations, youRSQUOll have to define these directories or disable trusted locations. See Add Trusted Locations
|Deploy customized files to the correct locations. Reflection looks for session files and supporting custom files in specific locations. If you deploy one of these files to another location, Reflection will be unable to find it. See Customized Files that Must be Deployed to Specific Locations in the Reflection Deployment Guide.
|Consider using the Reflection setup.exe. Setup.exe is the recommended tool for installing and deploying Reflection. This tool uses the primary Reflection MSI file to install Reflection but it also installs prerequisite software (if needed) and has several other features that provide a smoother deployment than installing directly with the primary Reflection MSI file. It determines whether each workstation has the required .NET Framework and Microsoft Windows Installer version and automatically installs them if necessary. It also automatically uses the correct language for the installation and removes previous versions of Reflection. If the Visual Basic feature is selected, Setup.exe also installs the Visual Basic core MSI, along with the appropriate VB language MSI.
|If you are deploying with MSI directly, make sure all prerequisites are installed. If you use msiexec.exe for your install, prerequisites are not installed automatically. If the required prerequisites are not already on your users' workstations, you need to install them separately. You can find installers for the required prerequisites in the Prerequisites folder in the distribution media, or in your administrative installation. The prerequisites you need to install depend on which programs and features you are installing. All Reflection Workspace features require Microsoft .NET Framework 4.8. If you attempt an install using msiexec.exe and this prerequisite is not found, a message displays and the installer stops. To install the .NET Framework, run the executable file in
Prerequisites\DotNet471. The Visual Basic for Applications feature requires Microsoft VBA 7.1. Use the core and language-specific *.msi packages in the
|Ensure your user systems meet Reflection Requirements To make sure users have the Reflection hardware and software requirements, see System Requirements.
|If your users have macros created with other products, install macro compatibility features. To run a macro created with another product, the Micro Focus compatibility feature for that type of macro must be installed. This feature is available on the Reflection Setup program Features tab, under 3270/5250
|Make sure that all VBA projects in referenced session documents and SharedMacros files have unique project names. If you are referencing session documents or using SharedMacros files to share macros, make sure the projects in those files have unique project names. Each project name in the VBA Project editor must be unique to avoid errors caused by naming conflicts. You can change project names by modifying the project properties in the VBA editor or by creating and saving these files in Reflection Desktop 16.2 or greater.
|Follow guidelines for setting up security certificates. You can configure certificate authentication for both Secure Shell and SSL/TLS connections. All SSL/TLS sessions require certificates for host authentication; without the necessary certificate, you cannot make a host connection. Depending on the host configuration, you may also need to install certificates for user authentication. Secure Shell sessions typically require both host and user authentication. Certificates can be used for either host and/or user authentication, but are not required by default. For more, see Digital Certificates and Reflection Certificate Manager.
|If you are using Citrix or AppV, Follow best practices for these platforms. Whenever possible, save sessions that have customized settings for QuickPads, keyboard maps, themes, mouse maps, hotspots, and ribbons as compound session document files (see Create and Customize Session Documents. This prevents problems caused by sessions not being able to access or find configuration files. If you specify a user data directory, do not use the Setup user interface to set the directory and do not use a drive letter as part of the directory. Setting the user data directory in this way on a Citrix server causes all users to have the same data directory. Instead, create a transform that sets the WRQ_USERDIR property to the location you want to use for the user data directory (see Add/Modify Registry Data and install Reflection with the transform. Be sure to use a Reflection property (such as
[PersonalFolder]) to specify the directory instead of a drive letter.