Issue The Vendor daemon fails to start on the License Server. Product Line EcoStruxure Building Operation Environment Ecostruxure Building Operation License Server Warning Potential for Data Loss: The steps detailed in the resolution of this article may result in a loss of critical data if not performed properly. Before beginning these steps, make sure all important data is backed up in the event of data loss. If you are unsure or unfamiliar with any complex steps detailed in this article, please contact Product Support for assistance. Cause The issue occurs due to special characters (e.g., ô, ã, non-breaking space) in the Computer Name of the operating system hosting the License Server. - see screen shot below. This can be observed in the FlexNet Publisher management page (localhost:8888). The taclic.log file may contain entries such as: 10:11:55 (taclic) Server started on Test-aã for: B 10:11:55 (taclic) client.station client.station graphdb.base 10:11:55 (taclic) server.cloud.customer server.enterprise.base server.es.as 10:12:08 (taclic) EXTERNAL FILTERS are OFF 10:12:11 (taclic) Unknown Hostname: Test-aã​ Resolution To resolve the issue: Edit the Computer Name of the host machine. Remove any special characters (e.g., accented letters, non-breaking spaces). Restart the License Server after making the changes.

Issue What type of communications cabling is recommended for Arcnet and Sigma LANs? Product Line Satchwell Sigma Environment Satchwell Sigma Cause Proper cable selection is essential to ensure reliable Sigma communication. Resolution For Sigma LAN communications, the following cable specifications are recommended: Standard One-Pair Communications: Use Belden 8762 or an equivalent cable. Isolated LAN Communications: Use Belden 9502 or an equivalent cable. Supporting Documentation: Belden 8762 Data Sheet (PDF) Belden 9502 Data Sheet (PDF) Additional Notes: Ensure cable installation follows manufacturer guidelines and local standards. Equivalent cables must match electrical and shielding characteristics of the recommended Belden models. Refer to the Satchwell Sigma Cabling Guide for further information

Issue When using SigmaX to unlock Sigma, the PC ID of the server machine may change, preventing clients from connecting. Product Line Satchwell Sigma Environment Sigma - All Versions SigmaX Cause Modern PCs often have multiple network ports. When SigmaX is used to unlock Sigma, the PC ID may change if a different network port is used for the main connection. This typically occurs when switching between wired and wireless connections. Resolution To prevent the PC ID from changing: Ensure the PC is connected via a wired Local Area Connection (LAN) when installing SigmaX. This connection will be used to generate the PC ID. Set the wired LAN as the primary network connection: Open: Control Panel > Network Connections > Advanced > Advanced Settings In the Adapters and Bindings tab, use the up/down arrows to move the Local Area Connection to the top of the list. Once set, you can safely use a wireless connection without affecting the PC ID.

Issue When launching SigmaX.exe, the following system error appears: SigmaX.exe - System Error  The program can't start because MFC71U.DLL is missing from your computer Product Line Satchwell Sigma Environment SigmaX Cause The Microsoft Foundation Class (MFC) libraries are typically installed by default on Windows systems. However, newer applications often rely on the .NET framework, and some versions of Windows 7 may not include all MFC libraries by default. Resolution Option 1: Manually Copy DLL Files If the error shown in Figure 1 appears, download the zipped file containing both MFC71.dll and MFC71U.dll. Download System32_MFC7_Files.zip Extract and copy the DLL files to: C:\Windows\System32 Option 2: Install Microsoft Visual C++ 2005 Redistributable Install the appropriate version of the Microsoft Visual C++ 2005 Redistributable Package, which includes the required DLLs. From Microsoft Website: Microsoft Visual C++ 2005 Redistributable Package (x86) Microsoft Visual C++ 2005 Redistributable Package (x64) Direct Downloads: Microsoft Visual C++ 2005 Redistributable Package (x86) Microsoft Visual C++ 2005 Redistributable Package (x64) Additional Notes Ensure you have administrative privileges when copying files to the System32 directory or installing redistributables. Restart your system after installation to ensure changes take effect.

Issue The LCES firmware for MP is universal, covers all models. The LCES firmware learns its model from the STM32 (the IO processor). If the LCES FW is unable to get an answer to the question, "what model am I", it defaults to MPC15A. When we see this, the reason is usually due to missing/corrupt STM32 firmware caused by a power fail during an uprev of the STM32 Product Line EcoStruxure Building Operation Environment Multi-purpose Controller Multi-purpose VAV Multi-purpose IO Warning Potential for Data Loss: The steps detailed in the resolution of this article may result in a loss of critical data if not performed properly. Before beginning these steps, make sure all important data is backed up in the event of data loss. If you are unsure or unfamiliar with any complex steps detailed in this article, please contact Product Support for assistance. Cause STM32 flash corruption is caused by interruptions during firmware activation, such as: Power cycling the controller before activation completes. Network disruptions during upgrade. Premature assumption that upgrade is complete based on “100%” progress bar. Resolution To recover, try the following: Manually factory reset the MP controller (Press and hold the reset button between 20-29 seconds) Upgrade the MP controller to a revision close but NOT the same as the current firmware version. When the firmware upgrade is complete, reset the controller or power cycle the MP controller. Collect the device report again and check if the model has been updated to the correct one. If the model is correct, upgrade to the original or desired firmware version. If the model is incorrect, attempt another upgrade with a different version , aside from the initial firmware, from Step #2. You may need to repeat the firmware upgrade two more times if unsuccessful. 

Issue BACnet/IP controllers are not configured in RSTP Mode by default, therefore must be configured during installation. Having RSTP Mode disabled by default allows one to connect BACnet/IP controllers to any switch, even with port security configured to detect BPDU packets and disable the port. Product Line EcoStruxure Building Operation, TAC IA Series Environment Multi-purpose Controller (MP-C) Multi-purpose VAV (MP-V) Room Controller IP-IO I/A Series N4 Jace8000 SmartX IP Driver for Niagara Cause RSTP protocol requires that controllers, switches, and network architecture are configured to ensure the protocol will operate as expected.  Resolution Setting RSTP Mode for BACnet/IP Controllers ALL devices in the RSTP loop MUST BE IN RSTP MODE to function properly. This is not a huge issue because during startup you can unplug 2nd side of the loop and it will function properly in a daisy chain. Ensure the SmartX Controllers are configured correctly Configuring BACnet/IP Controller Device Settings A factory or network reset returns the RSTP setting to Disabled. Important: Whenever you change RSTP settings, the controller MUST be WARM START. If you fail to perform this restart, the BACnet/IP controller will continue communicating using its previous RSTP settings. 'Activate IP Changes' does not affect RSTP mode. Ensure the switch is configured correctly per Configuring RSTP on a Managed Switch for SmartX IP Controllers. If asked to review this for a case, please provide PSS screenshots from the switch configuration page(s).  Bridge Priority = 4096 Hello Time = 2 sec Max Age = 40  (40 is the maximum value allowed by the protocol. Default is 20) Forward Delay = 21 sec Bridge Priority Considerations Change Bridge Priority by adding 4096 as switches get further away from AS. (8192, 12288, 16384, 20480, 24576, 28672) DO NOT set the priority as 32768 or higher because that is the built-in Bridge Priority of BACnet/IP Controllers. First, configure the Root Bridge Switch (closest to the Automation Server) settings. Then, configure the additional Switches in order of increasing Bridge Priority. {OPTIONAL}: Troubleshooting RSTP with Wireshark Plug in 2nd side of the RSTP Loop If all devices stay online, then it is working properly. Now test line breaks or controllers that are powered off. If all devices go offline and/or the switch LED is flashing rapidly, then go to RSTP Troubleshooting. Managed Switch Troubleshooting Consult the documentation or contact the vendor or manufacturer to assist with configuration for the items below. Ensure the switch is IEEE 802.1D - 2004 capable. BACnet/IP Controller Networking Term Definitions RSTP Ring mentions the Rapid Spanning Tree Protocol is specified in IEEE 802.1D - 2004. Ensure the firmware is up-to-date by contacting the vendor or manufacturer or downloading it from its website. Ensure ports not participating in RSTP are configured as Edge Port, Admin port, or have STP disabled. Nomenclature for those settings on your specific managed switch may vary. Adding BACnet/IP controllers to site-managed switches, work with Local IT to add these devices to their network. They will need to work with their switch vendor/manufacturer/support group to ensure the configuration of those switches because it could be more complex than changing the minimum recommended four settings above. Also, since RSTP Protocol is limited to Max Age = 40 (hops including site switches and BACnet/IP controllers), each loop's size may be limited based on their site switch network configuration and architecture.  Determined the proper configuration (or disable) for the following features. DHCP snooping Dynamic ARP inspection Denial-of-service (DOS) mitigations BPDU Guard BPDU Filter Energy-saving settings. Similar to Wake-on-LAN: the switch had minimal traffic, so ports entered power-saving mode. When they reactivated, the AS-P had already timed out, triggering a comm loss alarm. RSTP Troubleshooting Check each BACnet/IP Controller -> Diagnostics -> Device Report to confirm in RSTP Mode MANUAL CHECKOUT Double-click MP - Diagnostics Files - Device Report It will open in the default text editor Review the Device Settings section near the bottom. In firmware 1.00.0x, the report should report RSTP Mode: Enable In firmware 2.00.0x or higher, RSTP: Enabled and RSTP Status: Operational If it reports disabled, then perform Setting RSTP Mode for BACnet IP Controllers Step 1 until RSTP is working properly. USE SEARCH & EVENTS EBO 2.x MP Device IP and Settings.xml for EBO 2.0 as it only includes MP controllers EBO 3.x SmartX Device IP and Settings.xml for EBO 3.x or higher Import attached search USE RSTP STATUS GRAPHIC IN WEBSTATION MUST BE EBO 3.1 or higher which includes ClientAPI support Frontline Fridays Episode 02 - Rapid Spanning Tree Protocol (RSTP) Date: 2022-11-11 Mike Botens posted the following in the thread: RSTP Status TGML dated 2022-11-09 PDF of the presentation Fusion Fridays - Session 07 ​​​​ Date: 2020-05-28 The start of the video shows the graphics page in use RSTP Status.zip is downloaded via the link below the video. Extract the TGML and drop it on the AS to import. The suggestion is to store TGML directly under the AS to help with navigation in Webstation. bind Network to the BACnet/IP network with the BACnet/IP Controllers. (You may need a second TGML page if BACnet/IP controllers are on Primary and Secondary IP) Run from web browser via WebStation because utilizes ClientAPI KNOWN ISSUES Offline controllers that are scattered are NOT an RSTP issue. Check to see if there is a possible DHCP issue by verifying controllers are still at their AUTO-IP address (IP 169.254.nnn.nnnn Subnet Mask 255.255.0.0). RSTP communications issues affect the entire RSTP loop or one contiguous group of controllers. Factory Reset or controller replacement should leave one ethernet cable unplugged until configured for RSTP per these articles: Replace a BACnet/IP Controller in an RSTP Ring Network Workflow and MP Controller Reset Modes If BACnet/IP Controller Device Report OR RSTP Graphic reports RSTP Status: Changes Pending instead of RSTP Status: Operational, disable RSTP Mode, Warm Start, re-enable RSTP Mode, Warm Start, and check again. SmartX is now SpaceLogic. KNOWN ISSUES with Firmware affecting RSTP: If Firmware 3.02.01 is installed, please upgrade to 3.02.02. RSTP not performing as expected with Static IP addressing RSTP does not work well on RPC HW RPC-16-B HW revision 6

Issue During or immediately after a firmware upgrade, the RP-C controller may experience corruption of the STM32 processor's flash memory. This results in the controller misreporting its model type and becoming non-functional. Affected RP-C controllers may exhibit the following: Incorrect controller model appears during BACnet discovery or in the device report. Controller defaults to RP-C-16A-F-230V when STM32 is unresponsive. No communication between STM32 and main processor (LCES). Controller reset button has no effect (no LED blink sequence). Even if the actual model is RP-C-16A-F-230V, it will not operate correctly if STM32 is corrupted. Lack of response to the reset button is a key indicator of STM32 corruption. Product Line EcoStruxure Building Operation Environment  Room Controller (RPC) Warning Potential for Data Loss: The steps detailed in the resolution of this article may result in a loss of critical data if not performed properly. Before beginning these steps, make sure all important data is backed up in the event of data loss. If you are unsure or unfamiliar with any complex steps detailed in this article, please contact Product Support for assistance. Cause STM32 flash corruption is caused by interruptions during firmware activation, such as: Power cycling the controller before activation completes. Network disruptions during upgrade. Premature assumption that upgrade is complete based on “100%” progress bar. Resolution To prevent the issue, perform the following: Do not disturb controller operation during firmware activation. Ensure the following indicators are met before removing power: Firmware revision is updated in the “Firmware revision” column. “Upgrade status” shows Operational. Controller is Online (not just showing 100% progress). If STM32 corruption has occurred, follow these steps to restore the RP-C controller: Ensure prerequisites for your laptop: Enterprise Server with Demo License running 5.0.2.109 or higher EBO Workstation compatible with Enterprise Server version instructions are for DHCP network that laptop and controller are connected. Adapt for direct connection using Auto IP, if needed. Multiple SpaceLogic firmwares, as needed to use one different from the version the controller is currently running Launch EBO Workstation and log into Enterprise Server. Connect RPC to network via Ethernet. Apply 24VAC power to RPC. Open Device Discovery and initiate BACnet discovery using Discover All button. If RPC is not discovered, cycle power and retry discovery. Once discovered (likely as RP-C-16A-F-230V), host it to the ES IP network. Ensure ES has a different firmware version than the one currently on RPC. Go to Firmware Upgrade screen: Select a different firmware version. Choose Activate Immediately. Click OK to start upgrade. Wait for the status to change: “Download firmware in progress” → “Activate firmware scheduled” → “Activate firmware in progress”. RPC will go offline in 1–3 minutes. Wait 1 minute, then power cycle RPC (off for 5 seconds, then on). Wait another minute, then repeat power cycle. Within 10–30 seconds, Status LED flashes Red & Green (STM32 reprogramming is being performed). After ~1:15 minutes, LED flashes White & Green, then toggles Red & Blue (Bluetooth FW upgrade is being performed). There is an expected white and green flash of LED where the final LED state is Solid Green. Rediscover RPC in EBO. The controller should now report the correct model and be fully operational.

Issue Need to perform a diagnostic verification as a preventative measure during routine maintenance or reactively in response to cabling that is causing RSTP issues. Product Line EcoStruxure Building Operation Environment Multi-purpose Controller (MP-C) Multi-purpose VAV (MP-V) Room Controller (RPC) IP-IO Cause Issues can be caused by cabling or cabling terminations between controllers in the RSTP Loop. Resolution Reference RSTP Troubleshooting for BACnet/IP Controllers - Schneider Electric Community to ensure that: the managed switch is appropriately configured for RSTP all SpaceLogic controllers, on the RSTP loop, report RSTP Status = Operational Leave one side connected to the managed switch Plug the other end into a laptop running Wireshark Evaluate based on the information below Ensure both ends are not plugged into the managed switch at the same time by: Unplug the end from the managed switch Unplug the end from the laptop and plug it into the manage switch Take the free end and plug it into the laptop Evaluate based on the information below If it fails either evaluation, check the cables based on Message Age using a cable tester. It is optional but highly recommended to use a cable tester that displays cable length, as they tend to be more accurate, pointing out failures that other testers may report as passing. If it passes the evaluation on both ends, then one can plug in both ends into the managed switch Evaluation This capture shows a topology change (TC + Root) in RSTP, then settles out to a consistent Root Bridge Priority and Message Age. Your capture should only show a topology change when Wireshark is capturing on one end and the other end is connecting/disconnecting from the managed switch. Review the following fields: Root Bridge Priority - should be consistent and show the Priority of the Root Bridge. The root bridge can be the switch to which the RSTP loop is connected or a managed switch upstream. If it shows 32768, then another SpaceLogic controller assumed the root because it is not communicating properly back to the root bridge. (See Message Age Note) Message Age - should be consistent and show the expected number of controllers away from the root bridge. When Root Bridge Priority is 32768, you can use Message Age to determine how many controllers away the issue is occurring, checking the cabling connected to or close to that controller.

Issue In the LON Flow Balance program the k-factor calculated by the balance process can be displayed at the end of the procedure.  I cannot determine how to read it in the BACnet Flow Balance program.  The value is needed so that the application file can be updated so that if the controller needs to be re-downloaded, it will not need to be balanced again. Product Line TAC IA Series Environment BACnet  MNB-V1 or MNB-V2 controller WorkPlace Tech Tool software release 5.7.2 or newer (Optional, for backup) Cause The BACnet Flow Balance process uses a procedure that results in a more accurate flow calibration process. As a result of this process the rated box flow value does not get re-calculated during the balance process. Resolution The BACnet MNB-V1 & MNB-V2 controllers store Flow Balance calibration data separately from the application file. This ensures that a revised application can be downloaded without losing air balance calibration data. To access the updated k-factor: Navigate to the Flow Balance Data screen Click “Balance Data” in the left menu of the Flow Balance screen. This screen displays all data entered and generated during the balance process. Refer to Documentation See the figure “Flow Balance Reporting – Flow Balance Details” in Chapter 5 of the MicroNet BACnet Commissioning Tool / Flow Balance Users Guide (F-27358). Generate Reports Both the BACnet Flow Balance program and WorkPlace Commissioning Tool can generate flow balance reports for individual or multiple BACnet VAV controllers. Reports are automatically saved and can be viewed/printed in HTML format without reopening the tool. Backup and Restore Functionality WorkPlace Tech Tool 5.7.2 introduced a feature to back up the complete application, including: COV subscription data Flow balance calibration data If a controller is replaced, use the WorkPlace Commissioning Tool to restore the backup. Refer to the WorkPlace Tech Commissioning Tool Backup and Restore section on page 10 of the release notes (F-27526-3) for details. Additional Resources WorkPlace Tech Tool 5.7.2 Release Notes (F-27526-3)

Issue Are there any functional differences between the following part numbers? MNL-V1RVx vs. MNL-V1RVx-2 MNL-V2RVx vs. MNL-V2RVx-2 Product Line TAC IA Series Environment I/A Series Micronet LON VAV controllers Cause The original part numbers MNL-V1RVx and MNL-V2RVx have been replaced with MNL-V1RVx-2 and MNL-V2RVx-2, respectively. The datasheet F-26365 references the original part numbers (MNL-V1RVx and MNL-V2RVx). Resolution There are no functional differences between the original and updated part numbers. The addition of “-2” in the part number signifies a mechanical enhancement to the VAV actuator assembly. This enhancement was made to reduce the operational noise level of the actuator, improving acoustic performance without altering functionality. Refer to datasheet F-26365-8.pdf for more technical specifications.

Issue How do I use a Plain English program to unlock a list of doors by toggling a switch? Product Line Andover Continuum Environment NC2 ACX Plain English Cause Customer request of a sample Plain English program to unlock a list of doors by toggling a switch. Resolution This sample program is provided as a proof of concept only and is not intended as a complete solution but rather as a general guideline. Significant modifications may be required to adapt the sample program to an acceptable solution per local site requirements. The sample program as written works with a "maintain position" toggle switch, if site is using a "momentary" switch then the program will need modifications. Sample PE Program in PE Editor   See attached text file   

Issue Maintaining device uptime and ensuring data integrity is critical. This article explains the Device Firmware Upgrade (DFU) process, the meaning of “nosync”, and how we’re enhancing system reliability. Product Line EcoStruxure Building Operation Environment EBO version 5.0, 6. and later Cause What Is “nosync”? Introduced in SBO 1.5, the term “nosync” indicates an incomplete shutdown, which may result in data inconsistency. Devices in this state can be recovered using the DFU process. What Is the DFU Process? The Device Firmware Upgrade (DFU) process is a standardized recovery method that restores devices even when system data is corrupted—essentially reviving a “bricked” or “nosync” device. Instead of booting from internal firmware, DFU allows the system to boot using data sent via USB. Common use cases: Downgrading to an earlier software version. Recovering from failed shutdowns to restore functionality. How Our Devices Store Data—and Why Proper Shutdowns Matter? Unlike traditional computers, Automation Servers use eMMC memory for continuous data logging. The smallest writable unit is a 4096-byte block. To reduce wear, we use write caches that temporarily store data before writing it permanently. A proper shutdown ensures all cached data is safely written. Interruptions can cause data loss due to: Power Failure: If power is lost before the backup capacitor completes the write process. Linux Kernel Crash: Prevents proper data management and shutdown. Resolution Improving System Reliability with EBO 7.0 In EBO 7.0 and later includes a major reliability enhancement. The Automation Server will now perform a smart check of its last shutdown status. If an improper shutdown is detected, the system automatically runs the Linux fsck (file system consistency check). This helps determine whether a “nosync” state is truly warranted, reducing false reports and improving reliability.   This enhancement has also been included in EBO versions 5.x and 6.x via hotfixes:  EBO Hotfix 5.0.3.17009 (CP16) EBO v6.0.4.10001 (CP8)

Issue In Vista 5.1.1 an "Unable to request license" alarm appears every minute, although the license is installed and the system is operating correctly. Environment Vista 5.1.1 Cause Software limitation. Resolution Install TAC Vista Server and Workstation 5.1.1 Hotfix 17. This replaces hotfix 11 where this issue was originally addressed. See TPA-MALI-08-0022.01 for details.

Issue When logging into the web server of a Xenta controller using Mozilla Firefox 4 an error message is shown stating that the website is using an invalid security certificate.  When logging into Xenta server using Firefox 4 a certificate error is displayed as displayed below: The complete error screen reads as follows: This Connection is Untrusted You have asked Firefox to connect securely to 192.168.1.152, but we can't confirm that your connection is secure. Normally, when you try to connect securely, sites will present trusted identification to prove that you are going to the right place. However, this site's identity can't be verified. What Should I Do? If you usually connect to this site without problems, this error could mean that someone is trying to impersonate the site, and you shouldn't continue. Get me out of here! Technical Details (IP Address of Xenta) uses an invalid security certificate. The certificate is not trusted because it is self-signed. The certificate is only valid for (IP Address of Xenta) (Error code: sec_error_ca_cert_invalid) I Understand the Risks If you understand what's going on, you can tell Firefox to start trusting this site's identification. Even if you trust the site, this error could mean that someone is tampering with your connection. Don't add an exception unless you know there's a good reason why this site doesn't use trusted identification. Add Exception... How to install a self signed certificate. Product Line Satchwell MicroNet, TAC INET, TAC Vista Environment Mozilla Firefox 4 Xenta 511, Xenta 527, Xenta 555, Xenta 701, Xenta 711, Xenta 721, Xenta 731, Xenta 913 SSL Cause The default certificate in the Xenta web server is a self-signed certificate. Since the certificate is not issued by a recognized Certificate Authority the web browser (in this case Firefox 4) cannot validate the authenticity of the certificate and suggests that the user not continue to the website each time the user tries to access it. Resolution There are two possible resolutions: Install the self-signed certificate using the following steps: Expand the "I Understand the Risks" bullet then click the "Add Exception" button. Firefox will automatically retrieve the certificate from the Xenta server. Make sure to check "Permanently store this exception" and then click "Confirm Security Exception" The certificate is now installed and the warning screen will no longer show up when logging into the server. It may be necessary to restart Firefox for the changes to take effect. Note: The certificate will need to be installed in each client computer that accesses the Xenta server but once this complete it does not need to be done again. The exception to this is if the web address of the Xenta server is changed or if Firefox is uninstalled then reinstalled. Update: Starting in September 2014, all major browsers will be disabling 1024-bit roots within their trusted roots stores. Any SSL certificates chained to a 1024-bit root will no longer work on any browsers that takes this action or one that relies on another's root store (the self-signed certificate is 1024-bit). This means that you will still get the security warning even if you have installed the self-signed certificate. Purchase a certificate issued by a Certificate Authority (CA): These certificates are pre-installed into the web browser and will automatically prevent certificate errors from occurring on all client computers that access the web server. Note that these can be quite expensive and unless the Xenta web server is being hosted on the internet they are not necessary. Please see TAC Xenta Server - TAC Networks - Technical Manual for more information. See "There is a problem with this website's security certificate." when logging in to Xenta web server using Internet Explorer 8 for information on installing certificates into Internet Explorer.

Issue Start up of Continuum Workstation sees the below error. The Continuum Workstation may continue to start up if the OK button is pressed or may crash.   ContinuumServer.exe error An error occurred during initialization of Continuum Shared Memory by "ContinuumServer.exe". Please restart your system. If this problem persists, please contact technical support. Product Line Andover Continuum Environment Continuum v2.0 SP1 A Windows 32-bit Operating System Cause Beginning with the Andover Continuum 2.0 SP1 Release, Continuum applications now take advantage of the upper memory address space that is available natively on 64-bit Operating Systems (OSs). In order to access these memory addresses on 32-bit OSs, you must reconfigure your 32-bit OS to support applications that are Large Address Aware (LAA).  Resolution Enabled Large Address Aware (LAA). A Windows batch file is included as part of the Continuum 2.0 SP1 release that allows you to reconfigure your 32-bit OS to support applications that are LAA. You will need to ensure that Windows Firewall and Windows Defender are turned off and then run the "laa_update.bat" batch file as an administrator from the installation CD or zip folder.  See page 19 of the Cyberstation v2.0 SP1 Installation Guide for further details.

Issue In TAC Vista 5.1.9 when trying to lock a license file to an end user dongle, the taclic vendor daemon starts briefly, but then stops again and you see the error "Invalid license key (inconsistent authentication code)" in the taclic.log file. Usually you only see that message if the license file has been tampered with. 8:48:28 (taclic) Invalid license key (inconsistent authentication code) 8:48:28 (taclic) ==>INCREMENT Menta.View taclic 5.1 permanent 1 ISSUER=TAC \ ISSUED=30-may-2014 BORROW NOTICE=3424672 \ SN=FID__47eba299_146164ca427__7ec5 SIGN="13DC 795D AF25 E8ED \ D6EG 7BAA 8495 2ED7 B4B0 F6E4 EDD8 C3C1 6EAE 2BF0 598D 0759 \ AE4A 3C9E 391C A6ED B313 9971 369A 349C 8671 E194 2E42 E2DC \ 8A9A 7905" Product Line TAC Vista Environment TAC Vista 5.1.9 License Server Cause An issue has been detected in TAC Vista 5.1.9 when locking a license file to an end user dongle. You see the error "Invalid license key (inconsistent authentication code)" in the taclic.log file. The error is located in the taclic.exe file. Resolution Contact PSS for a permanent hotfix for this issue, or download it from Exchange Download Center.  Work around 1: Lock the license to the MAC address of the PC Follow Rehosting a Vista 5 License on the FlexNet License Server to rehost a license file to a MAC address.  Work around 2: Use a previous version of the taclic.exe file Access a PC having a previous version of the license server installed Locate the file "taclic.exe" and copy it - it's normally located in the TAC Vista installation folder under "License Server" Stop the license server on the PC having TAC Vista 5.1.9 installed Rename the original taclic.exe file to taclic_11.12.exe Paste the "taclic.exe" file you copied into the folder Start the license again  In general when working with the license system on TAC Vista versions from 5.1.8 and above, this utility can come in handy: TACLicenseServer Settings.

Issue Error message when opening Vista 5.1.5 Webstation: "HTTP Error 404.2 - Not found. The page you are requesting cannot be served because of the ISAPI and CGI Restriction List settings on the web server." Product Line TAC Vista Environment Windows 2008 server (32-bit & 64-bit). Webstation 5.1.5, 5.1.6, 5.1.7 Cause ISAPI (Internet Services Application Programming Interface) and CGI (Common Gateway Interface) services are not activated by default in Windows 2008 Server. Resolution After following the installation instructions in the Vista 5.1.5 TPA-VSTA-11-0002.01 (or Send to controller fails with "Not enough memory" error in Distribution View) do the following: Click on Start and then Run. Type inetmgr Once Internet Information Services Manager has opened, change to "Detail View" in the View menu. Double-click on ISAPI and CGI Restrictions Feature.   Under the "ISAPI and CGI Restrictions" right-click on ASP.NET v4.0.30319 and select "Allow". Webstation should now work.

Issue Error: "Could not create remote directory" or "Failed to establish connection with the target device" when trying to upgrade/downgrade a Xenta 5/7/9xx controller     Product Line TAC INET, TAC Vista, Satchwell MicroNet Environment Xenta Servers Xenta 511, 527, 527-NPR, 555, 701, 711, 721, 731, 913 XBuilder Warning Potential for Data Loss: The steps detailed in the resolution of this article may result in a loss of critical data if not performed properly. Before beginning these steps, make sure all important data is backed up in the event of data loss. If you are unsure or unfamiliar with any complex steps detailed in this article, please contact Product Support for assistance. Cause This error can be caused by any of the following reasons: Trying to downgrade a Hardware version 2.x Xenta Server device to System Program version 2.10 or older Internet Options are configured to use a proxy server IP communication is not properly established due to incorrect IP settings, a bad cable or a faulty device The controller is 5.1.8 or lower and Microsoft KB 2661254 or KB 2661254-V2 is installed on the PC. In this upgrade Microsoft has changed the criteria for the certificate Key. Service packs are available on the extranet to correct this issue. Download blocked because of other Windows updates SSL 2 and 3 is not activated Resolution First, establish that the System Program that you are attempting to load is compatible with hardware version of the device. The older HW 1 versions can be upgraded to System Program 5.1.2 or older. Only system program versions 2.2.0 and newer can be loaded into devices that are hardware version 2.X. Hardware Version System Program 1.0 5.1.2 or older 2.X 2.2.0 or newer 3.X 5.1.6 SP1 or newer Note: Hardware version 1 devices are not labeled as HW 1 since only one version of hardware existed at the time. Hardware devices can be identified by the lack of any hardware version printed on the Neuron ID sticker. Note: If running the firmware update software, ensure you are running as an administrator. Next, check to verify that IP communications are configured properly and are functional: Check the IP address defined in XBuilder Verify a good connection to the IP port of the controller (10Base-T port on the far right) with a crossover cable. If that is all good, then a reformat of the controller may be necessary. Connect via Hyperterminal to the unit and at the dsh> prompt type format and press enter command . This will recreate the directory structure of the controller and allow you to attempt the upgrade/downgrade again. Finally, verify that the Internet Options are not configured to use a proxy server or, if they are, temporarily change them as follows: To temporarily change this setting follow these steps: In Internet Explorer select the Tools Menu and select Internet Options. Or select Internet Options from your Control Panel. Go to the Connections tab. Click the LAN settings button. Uncheck the Use a proxy server for your LAN box. Click Ok in the LAN settings window and the Internet Options window. Complete the System Program download. Return to the Internet Options window and re-check the Use a proxy server for your LAN box in the LAN Settings found in the Connections tab. Another Matrix explaining the compatibility of each with Vista versions can be found in Xenta-Server-firmware-versus-Vista-Server-versions If you have the Xenta FW 5.1.8 or lower and KB 2661254 or KB 2661254-V2 were installed during a Windows Update you will need install the service packs. These new service pack builds have been released and are available on the extranet. See TPA-VSTA-12-0028.00 - TAC Xenta Servers, Not Possible to Download Firmware for more info. Another issue has been reported to support relating to the bit length of the Xenta server boot certificate. The Xenta server installer uses a 512 bit key length of the boot certificate, and Windows in some instances can be configured for a 1024 bit length certificate. If the issue still exists after removing the above mentioned Windows Updates, or if you are getting this error and the Windows Updates are not on your machine. Download the attached tool, Allow Weak Certificates.zip, and execute the file, chose "Allow Weak Certificates", and "Update".   Here is what the tool set: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config] "EnableWeakSignatureFlags"=dword:00000002 "minRSAPubKeyBitLength"=dword:00000200 If taking the preceding steps fails to resolve the issue then see the following articles for additional steps that can be taken: Xenta Server "Run" light is solid red, with no communication via Ethernet,  Fail to upgrade the TAC Xenta Server system software (firmware)  An unexpected error occurred while downloading using a Xenta Server

Issue Vista 5.1 license is not working.  Trying to launch Vista components results in error:  lc_checkout failed: Cannot checkout an uncounted license within a Windows Terminal Services guest session. Environment Vista 5 Terminal Services Virtual Machine VM Cause There is a special feature needed in the license which allows the use of Terminal Services. Resolution You must download the 14 day Demo TS Evaluation License on The Exchange Download Center. *note that Terminal Services are only supported in Vista 5

Issue On December 13, 2012, the certificate verifying the authenticity of the Schneider Electric I/A Series G3 Workbench Applet (wbapplet) expired. Users will see the following error in their browser when accessing a station that is using a version of the wbapplet.jar with an expired code signing certificate: Environment Niagara G3 Cause When accessing an I/A Series G3 station through a web browser using a WbWebProfile, the web browser runs Workbench within a Java applet. To enhance security, this applet is 'signed' using a code signing certificate. This ensures that the applet has come from a reliable source and can be trusted to run with the proper permissions. Certificates used to sign applets are issued by a Certificate Authority (CA). Each code signing certificate issued by a CA has an established expiration date, with the maximum expiration being two years. Once this expiration date has passed, continuing to use a Java applet with an invalid certificate will result in warning messages within the browser. The applet will only be allowed to run after the user has acknowledged the warning and granted approval. Resolution An updated certificate is available in the new wbapplet.jar, available from The Exchange Download Center. This file will need to be added to the Enterprise Network Server, as well as on any ENCs that will be accessed from a browser. This file is for all released versions of TAC I/A Series G3 and is valid until March 30, 2015. Download wbapplet_March_2015.zip. Extract the wbapplet jar file  Click and Download The WbApplet Installation Guide. Note: Updated WbApplet files are available as part of upcoming Niagara 3.5 and 3.6 maintenance builds, as well as being from the Source website. In 3.7, wbapplet.jar is integral to the web.jar and contains an up to date certificate.;