Upgrade considerations for versions before 8.7

This page is for users upgrading from a version earlier than 8.7. It covers all backward-incompatible changes that might affect you, as well as other important considerations to keep in mind when upgrading to the latest version. Be sure to review the relevant sections based on the version you're upgrading from.

• Version 8.0 or earlier
• Version 8.2 or earlier
• Version 8.2.6 or earlier
• Version 8.3 or earlier
• Version 8.6 or earlier

NOTE: In addition to this page, see Upgrade considerations for upgrade information starting from version 8.7 onward.

TIP: If you have questions or need help, please contact Alloy Professional Services Team at support@alloysoftware.com.

Version 8.0 or earlier

Pager field removed from Person records

Backward-incompatible change

The Pager field has been removed from Person records as obsolete. The contents of that field are imported into the user-defined field UDF_Pager, and the business logic involving this field is updated correspondingly.

If you have any reports or views based on the Pager field, you will need to review them and update as necessary.

Version 8.2 or earlier

Sharing properties removed from KB Articles and Library Items

Backward-incompatible change

The upgrade removes the Shared_with_Everyone column from the KB_Articles and Library tables, and deletes the Library_Item_Organizations and KB_Article_Organizations tables.

If you have any reports or views based on these items, you will need to review them and update as necessary.

Version 8.2.6 or earlier

Welcome to Mobile App

Backward-incompatible change

All technicians who used to work with the Mobile Portal should be instructed to install our new Mobile App on their mobile devices. Alloy Navigator mobile app is available for iOS and Android mobile devices on Google Play and App Store.

Requests from mobile web browsers to the Web App will not be redirected to the Mobile App anymore.

Version 8.3 or earlier

Discontinued support for Internet Explorer and older browsers

We maintain and develop the Alloy Navigator platform to support the latest, most stable, and most secure web browser versions. We highly recommend updating your browser to the latest version to have the best and most secure user experience across our services.

Starting with version 8.5, we dropped support for Microsoft Internet Explorer 11 (IE11) and older versions. Product updates and new features are no longer being tested on Internet Explorer, and we no longer provide fixes to bugs that occur exclusively on Internet Explorer.

For the list of supported web browsers, see Installation Guide: Web Client Requirements.

Version 8.6 or earlier

PowerShell instead of CMD in integrations

Backward-incompatible change

Starting with version 8.7, the Alloy Navigator Expressworkflow engine uses PowerShell instead of CMD in integrations with external tools and utilities. Network Inventory also gives up CMD in favor of PowerShell.

PowerShell is much more than just a shell. It is a powerful scripting environment that can run complex scripts and automate system administration tasks. Now you can leverage advanced PowerShell capabilities for more efficient solutions.

Among other things, PowerShell can be used to launch external programs, like CMD was used in previous versions. In most cases, native CMD commands are available in PowerShell through aliases. However, there are times when names or syntax of native CMD commands might be misinterpreted. That's why we strongly recommend that you review all your custom integrations after the upgrade to make sure that they work as expected.

The first thing to consider is the location of your external programs. The best practice is to add paths to directories where programs reside to the PATH environment variable. This will help PowerShell find the programs by the name of their executable files. Some standard programs, such as Ping or Remote Desktop, can be run just by typing the filename because their directory path (C:\Windows\System32) exists in the Windows search path by default. An alternative method is specifying full paths to programs. However, this method requires that the path is the same on all computers from which the workflow action is initiated.

See the table below for some issues with your custom external commands integrations that you may experience after the upgrade and how to resolve them.

Issue	Description	Solution
PowerShell cannot understand the path enclosed with quotes and sends that path it to the output. When the command contains parameters after the path, this error occurs: Unexpected token 'Parameter' in expression or statement.	If you specify a path for an external program in CMD, and the path contains spaces, you must enclose the path with double quotation marks ("). PowerShell considers commands enclosed with quotation marks as PowerShell strings, or objects of the type "String." PowerShell cannot execute strings. When passed a string, it simply attempts to send it to the output.	Add an ampersand character (&) before the first quotation mark in the path. The ampersand is the Call operator that tells PowerShell to treat the string expression as a command to be executed. For example: INCORRECT: "C:\Program Files\RealVNC\VNC4\vncviewer.exe" LT00054 CORRECT: & "C:\Program Files\RealVNC\VNC4\vncviewer.exe" LT00054 NOTE: Make sure that the executable file exists on all computers from which the workflow action is initiated, and the path is the same. Alternatively, add the path to the program to the PATH environment variable, and then delete the path with the quotes from your integration.
PowerShell cannot find the external program that you are trying to launch. This error occurs: program.exe : The term 'program.exe' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.	PowerShell cannot find programs when their paths are not specified, either explicitly or in the PATH environment variable. For example, if your program is in the Bin directory of Alloy Navigator Express, it could be previously executed by just typing its name, because the product could find that program without the need to specify the path to it. Now, when launching external programs is delegated to PowerShell, PowerShell knows nothing about where the executable file is located, and cannot find it.	Add the path to the program to the PATH environment variable. Alternatively, specify the full path to the program, enclose it in double quotation marks if it contains spaces, and add an ampersand (&) before the first quotation mark. TIP: Our native programs from the Bin directory, such as Alloy Screenshot or WakeOnLan, are not an exception. Now you should specify the full path to the Bin folder, or add it to PATH. NOTE: Make sure that the executable file exists on all computers from which the workflow action is initiated, and the path is the same.

INFO: For additional information, see Administration Guide: Creating Integrations.

INFO: You can find the official product documentation for PowerShell at https://docs.microsoft.com/powershell/.

Integrations in the Web App

Starting with version 8.7, External Command workflow operations are available not only in the Desktop App, but also in the Web App and the Self Service Portal.

When Web App users run a workflow integration for the first time, the Web App prompts them to instal the Alloy Integration Launcher. As soon as they have the launcher installed, Web App users can launch all integrations. Desktop users get the launcher installed automatically, along with their desktop applications.

Integrations themselves are the same, no matter from which app users launch them, and use PowerShell to execute scripts, cmdlets, or external programs. All your custom Integrations that work in the Desktop App will be available in the Web App now.

Native API integration for the Mobile App

Starting with version 2.0, Alloy Navigator Mobile App no longer needs the Mobile App Service (formerly, "the Mobile Portal") as a backend. Instead, it uses the native API integration, which significantly improves the application performance.

Starting with version 8.7, we are retiring the Mobile App Service and replacing it with the API module. As soon as you upgrade the Mobile App Service from version 8.6 or earlier and your technicians update their Mobile App to version 2.0, the app will prompt them to update the application URL, warning that the existing address is being deprecated. However, technicians will still be able to use the "deprecated" URL until you are ready to install the API module of the latest version.

TIP: When you are ready, switch the Mobile App to the native API integration. For instructions, see Installation Guide: Switch the Mobile App to the Native API Integration.