ERP Applicable: Vista
Author: Eric Vasbinder
When using our modern Vista ERP clouds, Trimble Construction One (TC1) and Viewpoint One (VP1), our customers will experience Vista Remote Link (VRL) as the primary, and many times sole, connection mechanism to use to connect to our cloud. VRL is extremely powerful and allows for the Vista rich client application to be installed on end user local workstations. Most times, this works well and provides end users with a uniquely robust ERP experience. In order to provide this power, certain aspects of VRL are implemented differently than the architecture of on-premise Vista, which uses the LAN connection mechanism. The LAN connection mechanism has been used by Vista for nearly 30 years and continues to be the primary connection mechanism for Vista on premise. Due to this legacy, unfortunately, certain narrowly defined workflows are more advantageously performed for some users in the LAN method as compared to VRL today.
In most cases, there is no substantive negative difference between on premise Vista using the LAN method and cloud based VRL Vista. However, certain specific, narrow workflows are experienced differently with VRL versus LAN. Two particular areas are currently of note in this regard:
some error messages provided by the crystal reports engine in VRL are more generic than those provided by the LAN method: LAN method error messages are sometimes more descriptive, providing additional troubleshooting assistance for crystal report developers.
LAN Method has an extra Print Button
The LAN connection method Crystal reports previewer contains a button to allow for direct printing from the previewer, whereas the VRL version of the previewer lacks this button. VRL users need to utilize the report launcher screen to print a report directly to a printer.
Report Column Formatting
the LAN method renders reports through a Different report previewer than the VRL method. This can avoid some potential report formatting issues with VRL's previewer only (NOTE: These formatting issues are not usually present in the printed copies of reports or PDF exports of those reports. The formatting issues that are encountered are often only encountered in the previewer itself).
As the LAN Method downloads the actual data for the report to the Crystal Reports engine on the local workstation, the time it takes to render the report locally can sometimes be significantly reduced. Especially when going from page to page in the report; again, all the data is stored locally for the Drilldown report, vs. the VRL method which sends the pre-rendered report only, page by page, down to the local client.
Using the LAN method as a workaround to any encountered VRL issues is a good approach but has one major downside: unless the Vista rich client is running in the same datacenter as Vista (e.g. over our RDP), performance for data entry can be slower than VRL. Nearly every speed demon initiative for performance that has been pushed through in the past few years has been focused on either back end database performance OR VRL performance. These efforts have NOT touched data entry with the LAN method. As such, when using this method over an IPSEC VPN, you may find it to be measurably slower than VRL for data entry. However, this should not be greatly impactful for you, as data entry is NOT the intended purpose for this workaround.
There are two main routes that a user might be able to take in our VRL-based TC1 and VP1 clouds to be able to use the LAN connection method when absolutely necessary:
Option A (Deprecated / Legacy Clouds ONLY): RDP connection directly to Viewpoint-provided RDP Terminal Server
Option B (PREFERED): the LAN connection method over an IPSEC VPN tunnel to LOCAL workstation
This selection requires that Trimble Viewpoint host the actual Vista rich client application, along with Microsoft Office, Adobe Acrobat, Spreadsheet Server, and other rich client tools directly on our Terminal Server in our cloud environment. This has the advantage of providing a complete thin client experience, eliminating the need to run Vista or any other component on your local workstation. The caveat to this method is twofold: first, this method is much more sensitive to performance issues with printing and scanning than running the Vista client on your local computer (among other downsides) and second, eventually the use of Trimble Viewpoint's RDP services to host the rich client for Vista will go away, with all rich client access and hosting being performed on local workstations or customer-hosted Azure Virtual Desktop instances.
IMPORTANT REMINDER: VIEWPOINT PROVIDED RDP TERMINAL SERVICES IS ONLY AVAILABLE FOR LEGACY CLOUD CUSTOMERS (VEC RDP and VIEWPOINT FOR CLOUD / VFC). TC1 CUSTOMERS MAY MAKE USE OF OUR RDP TERMINAL SERVICES FOR A SHORT TIME WITH DOCUMENTED NETWORK LATENCY ISSUES.
This choice utilizes the same Vista rich client that has been installed for VRL, residing on your local workstation. As such, many of the same VRL advantages hold true for this method as do for VRL. The uniqueness with this method is that it does not work outside of a network that has a site to site IPSEC VPN tunnel, joining our cloud network to the network within which your local workstation(s) sit. The other main advantage for this method is that it allows for simple use with no ongoing changes to the way that end users access Vista. The main downside to this LAN over VPN Connection method is that the end user leveraging this method MUST be on their corporate network that is joined to our cloud with an IPSEC VPN. This can happen by either the end user being physically located in the corporate office where the IPSEC VPN is set up OR by being remote, but connected to the corporate network with a client VPN (e.g. SSL / TLS VPN like Cisco Anywhere).
REMINDER: The performance of this method for data entry can be less than VRL due to lack of performance optimizations with the LAN method.
The process to set up the LAN connection method is fairly straightforward for cloud hosted customers and requires a few items be set up ahead of time:
Standard Architecture customers:
The IP address of the CODED1 server (where "CODE" is your unique, 3-4 character alphanumeric cloud customer code and D1 is the main Vista combined app and database server designation).
Enterprise Architecture customers:
The IP address of the CODE-DB1 server (where "CODE" is that unique, 3-4 cloud customer code mentioned above and -DB1 is the main Vista database server designation).
The IP address of the CODE-APP server (where "CODE" is that unique, 3-4 cloud customer code mentioned above and -APP is the main Vista app server designation).
Set up an IPSEC VPN
Follow the instructions at this URL and do not forget to whitelist the subnets of all local workstations, as well as any remote VPN user subnets that might need to use the LAN method in the future: How do I set up an IPSEC VPN to access my Vista database directly?
The following steps are necessary to set up the LAN Method over the VPN, once the IP is known and the VPN is configured.
Submit Cloud Engineering support request to have the following ports opened up for communication OVER THE IPSEC VPN to your Vista database server's private IP (reminder: this was identified above in step 1 of the previous section):
445
1433
1434
51515
51516
Update your .HOSTS file (C:\Windows\System32\drivers\etc\hosts) on your local workstation to have your local system now have the ability to properly resolve the private DNS names of the Vista server to the private IP Address. The form of the addition should look like this:
CODED1.viewpoint.local IPADDRESS
CODED1 IPADDRESS
Once these two lines are added, you may open a Powershell or command prompt window to attempt to ping those DNS names. If you are able to successfully ping those names, you are good to proceed to step 3.
Update your .HOSTS file (C:\Windows\System32\drivers\etc\hosts) on your local workstation to have your local system now have the ability to properly resolve the private DNS names of the Vista server to the private IP Address. The form of the addition should look like this:
CODE-DB1.viewpoint.local IPADDRESS
CODE-DB1 IPADDRESS
CODE-APP.viewpoint.local IPADDRESS
CODE-APP IPADDRESS
Once these lines are added, you may open a Powershell or command prompt window to attempt to ping those DNS names. If you are able to successfully ping those names, you are good to proceed to step 3.
Open the Vista client and add the new server name for the LAN Method:
click the plus sign
Add the new server name CODED1.viewpoint.local to the server name field and click the check mark.
If successful, you can then log in via the LAN method by clicking on the "Log in with Viewpoint ID" button for SSO login.
If you're able to log in via the LAN method, you'll see the name "VEC" in the local right hand corner of the Vista main menu screen, instead of VRL Cloud. This will mean that you are using the LAN method over the VPN to connect to a TC1/VP1 environment.
Open the Vista client and add the new server name for the LAN Method:
click the plus sign
Add the new server name CODE-APP.viewpoint.local to the server name field and click the check mark.
If successful, you can then log in via the LAN method by clicking on the "Log in with Viewpoint ID" button for SSO login.
If you're able to log in via the LAN method, you'll see the name "VEC" in the local right hand corner of the Vista main menu screen, instead of VRL Cloud. This will mean that you are using the LAN method over the VPN to connect to a TC1/VP1 environment.
Screenshots of updating hosts file and testing name resolution
Screenshots of updating the login client server name.
Screen shots of LAN method in action
changelog
Thursday, 14 September 2023 at 03:08PM:
added reference to drilldown reports potentially being faster via the LAN method.
Wednesday, 06 September 2023 at 10:22AM:
revised to include instructions for Enterprise Architecture customers.
Monday, 13 February 2023 at 10:29PM:
Initial Posting.