Issue Additional troubleshooting information is required for issues involving Mercury controllers in Access Expert. Product Line EcoStruxure Access Expert Environment Mercury controllers LP Series controllers Cause Controller issues require additional diagnostic information for troubleshooting and analysis. Resolution 1. Use Live Monitoring Use Live Monitoring while the issue is occurring to identify any error messages being generated.   2. Collect SEQ Logs SEQ logs provide more detailed error information than Live Monitoring. Install and collect SEQ logs for additional diagnostics.   3. Configure Controller Diagnostics with Acre Schedule a troubleshooting session with Schneider Electric Product Support, who will coordinate a phone call and remote session with Acre/Feenics support. During this session, the controller will be pointed to their debugging server. This allows diagnostic logs to be collected and provided to HID/Mercury for further analysis. This step is typically only required after Live Monitoring and SEQ log collection have been completed and is rarely used.   4. Collect a Syslog from the Controller For LP Series controllers, use the Syslog button on the Diagnostic page of the controller web interface. The downloaded syslog is an encrypted system log used by HID/Mercury support for advanced troubleshooting. The file must be provided to HID/Mercury support for analysis. The syslog is erased each time the controller reboots and therefore does not contain historical information from before the last reboot. Syslog files have the .aes file extension. This method should only be used when requested by HID/Mercury support and is very rarely required.

Issue Downstream interfaces/controllers appear as Unknown or remain Offline in Access Expert and cannot be brought online. Product Line EcoStruxure Access Expert Environment Downstream controllers/interfaces Cause Offline downstream interfaces can occur for several reasons: The downstream controller has not been set to Active after being added to the system. Interfaces were added after the controller was already activated, and the controller has not been rebooted to receive the new configuration. DIP switch settings or device addressing are incorrect. RS-485 wiring is incorrect. End-of-line (EOL) termination is not configured correctly. Duplicate addresses or baud rate mismatches exist on the RS-485 network. Power supply issues prevent downstream devices from communicating reliably. Resolution 1. Verify Device Activation Navigate to the controller configuration page. Confirm that the downstream interface/controller is set to Active. If the interface was recently added, perform a Full Download or reboot the main controller to force the updated configuration to download. 2. Reboot the Controller Reboot the controller associated with the offline interface. This allows the controller to download and apply the correct configuration. 3. Verify DIP Switch Settings and Addressing Check that the DIP switch configuration matches the settings configured in Access Expert. Switches 1–5 define the device address in binary (addresses 0–31). The address configured in Access Expert must match the physical DIP switch address. Switches 6 and 7 define the baud rate. The default setting is 38400 baud with both switches ON. Switch 8 should be OFF to disable AES key encryption. Communication is encrypted through TLS 1.2. Note: DIP switch orientation may appear inverted compared to labels on other connectors. For example, on an MR52 board, the ON label is located below the switch bank. 4. Verify RS-485 Wiring Ensure all panels are wired correctly according to the hardware installation guide. Verify RS-485 communication wiring polarity and continuity. Use a true daisy-chain topology. Avoid star configurations and wiring stubs. 5. Verify End-of-Line (EOL) Termination Confirm that EOL termination jumpers are configured according to the hardware installation guide. Enable termination only on the last physical controller in the RS-485 chain. 6. Verify Address and Baud Rate Consistency Inspect the physical DIP switches on all downstream controllers. Ensure each downstream controller has a unique address. Verify that software-configured addresses match the physical settings. Confirm that all devices on the same RS-485 segment use the same baud rate. 7. Isolate the Affected Controller Disconnect the second downstream controller from the RS-485 network. Verify whether the first controller remains online. Connect only the second controller to the main board. If the controller still fails to communicate, investigate: Duplicate addressing RS-485 communication hardware faults Local power supply issues 8. Verify Power Supply Health Measure voltage at the downstream controller power input. Confirm voltage remains stable between 12 VDC and 13.8 VDC under load. Low or unstable voltage can cause controllers to go offline, especially when readers, door strikes, or other peripherals draw power.

Issue Create a solution with an alarm definition and event filtering that will pulse an output to a phone dialer for alarm monitoring. Trigger the dialer when another output is active and when any of the inputs for door contacts, motion sensors, etc. have become active. Perform this solution on an Access Expert Intrusion only system without any readers. Product Line EcoStruxure Access Expert Environment AccessXpert Intrusion system with no readers Cause Without Security Readers, there is less hardware to process and monitor the logic required for a solution. Event filters cannot reliably evaluate both an input event and the current state of a separate output together. Resolution The following approach can be implemented using hardware I/O-level logic. This method combines the required conditions externally and presents them to the system as a single input event, eliminating the dependency on multi-event evaluation within the filter query.   Concept Create a single system input that activates only when: The original input condition (GC/PIR/DC) is active, and The Notification Active output is active. This is achieved by using outputs and relay contacts wired in series, allowing the system to see a single input that represents both conditions being true.   Wiring Logic Once dry contacts are available, wire the following relay contacts in series: Output driven by the input condition (GC/PIR/DC) Notification Active output The series relay path is then connected to a spare input, referred to as the Notification Alarm Input.  The Notification Alarm Input will only activate when both relay contacts are closed, meaning: The original input condition is active, and The Notification Active output is active. Implementation Step 1: Create an Output for the Original Input Condition Configure the original input condition (GC/PIR/DC) to activate a dedicated output. This output will serve as a representation of the input condition in the relay wiring scheme. Step 2: Obtain a Dry Contact from the Notification Active Output Depending on how the Notification Active output is configured: Scenario A – Dry Contact Relay If the Notification Active relay is being used strictly as a dry contact and is not switching external voltage, it can be used directly in the series wiring. Scenario B – Power-Switched Relay If the Notification Active relay is switching power (for example, 12VDC to a device), it should not be used directly in the input circuit. An isolated relay should be added to provide a dry contact interface. Scenario C – No Spare Outputs Available If no spare outputs are available, an external relay may be driven from the existing Notification Active output. The dry contacts from this relay can then be used to complete the series wiring.   Alarm Workflow The resulting sequence is as follows: A GC/PIR/DC input event occurs. The event activates the dedicated input-driven output. The Notification Active output remains active for its configured timer duration. The input-driven output and the Notification Active output are wired in series. When both conditions are present, the signal is sent to the Notification Alarm Input. The Notification Alarm Input triggers an Alarm Definition. The Alarm Definition activates the Alarm Monitoring Service Notification Output. The Alarm Monitoring Service Notification Output generates a pulse to the dialer. Workflow Diagram C/PIR/DC Input        │        ▼ Input-Driven Output        │        ├──── Series Wiring ────► Notification Alarm Input        │ Notification Active Output        │        ▼ Alarm Definition        │        ▼ Alarm Monitoring Service Notification Output        │        ▼ Dialer Pulse   Testing Results This approach has been tested and confirmed in a lab environment to produce consistent results, allowing the system to trigger only when both conditions are present.   Conclusion When Alarm Definition Filters cannot reliably evaluate an input event and a separate output state together, combining the logic at the hardware I/O level offers a reliable alternative. By wiring the input-driven output and Notification Active output in series to a dedicated Notification Alarm Input, the system can accurately trigger the Alarm Monitoring Service Notification Output and generate the required dialer pulse. Note: The above multi-step solution is needed for success. When attempting to create this with a single Trigger and Procedure, it would not work and would produce an error in Access Expert. “Filter references element that is not in the event data. Element 'Output' not found.” This occurs when a filter attempts to evaluate both input and output conditions together and fails to trigger as expected.   The filter references the “Output” field in event data where that field does not exist. Input-driven events (such as DC, PIR, or GC) typically only contain “Input” and “Status” fields and do not include “Output.” As a result, combining input and output conditions within a single filter causes the evaluation to fail because both cannot be processed together in the same event context.

Issue Otis Destination Dispatch integration with controller models MP4502 and LP4502 experiences instability where Destination Entry Controllers (DECs) repeatedly cycle online and offline, and elevator access control intermittently stops working. In some cases, controllers remain online locally but appear offline in the system, and elevators either do not respond to badges or allow free access. Temporary workarounds such as rebooting the controller, modifying IP settings, or adding/removing a reader restore operation for a limited time before the issue reoccurs. Product Line EcoStruxure Access Expert Environment Mercury MP4502 controllers (firmware 2.7.x, 2.9, 2.10) Mercury LP4502 controllers (firmware 1.29.x, 1.30.x) Otis Destination Dispatch integration Otis Compass 360 system Warning Potential for Data Loss: Ensure all important data is backed up before proceeding. Cause Instability occurs when using Mercury MP4502 controllers with Otis Compass 360 Destination Dispatch systems, resulting in intermittent loss of communication between the controller and Destination Entry Controllers (DECs).   Mercury MP4502 firmware has been validated with earlier Otis Compass integrations, but not explicitly with Compass 360. In this scenario, MP4502 firmware versions (2.7.x through 2.10) establish communication over TCP port 3001, however, sessions do not remain stable, leading to repeated disconnect and reconnect behavior.   The issue does not occur when using Mercury LP4502 controllers running firmware 1.30.2, indicating a compatibility limitation between MP4502 firmware and the Compass 360 integration in this configuration. Resolution Stability was achieved by replacing the MP4502 controller with an LP4502 controller running firmware version 1.30.2. After this change, DEC devices no longer exhibited online/offline cycling and the integration remained stable during operation. Additional actions taken during troubleshooting included: Upgrading MP4502 firmware to version 2.9, which did not resolve the instability Attempting firmware downgrade, which was unsuccessful Performing multiple temporary workarounds (controller reboot, IP refresh, configuration changes) that restored functionality only temporarily The validated outcome is that LP4502 firmware in the 1.x branch provided stable operation for the integration, whereas MP4502 firmware versions tested did not consistently resolve the issue. Continued coordination with vendors is required for a fully supported and validated solution for Compass 360 with newer hardware.

Issue A technician or user needs to identify the IP address configuration of a Windows workstation. This is commonly required during troubleshooting, commissioning, or connecting to BMS servers and controllers. Product Line Andover Continuum, EcoStruxure Access Expert, EcoStruxure Building Operation, EcoStruxure Security Expert, Satchwell BAS & Sigma, Satchwell MicroNet, TAC IA Series, TAC INET, TAC Vista Environment Windows Operating Systems (Windows 95 through Windows 11) Cause The IP address, subnet mask, or gateway of the PC must be confirmed to ensure correct network communication with building automation devices. Typical scenarios include: Unable to connect to Automation Server BACnet or Modbus devices not discovered PC on the wrong subnet DHCP not functioning Verifying network configuration for onsite support Resolution The following methods show how to retrieve IP information across different Windows versions. 1. Windows 7, 8, 10, 11 (Modern Operating Systems) Command Prompt Method Open Command Prompt: Press Windows Key + R, type cmd , press Enter Or search for “Command Prompt” Run: ipconfig Sample Output Windows IP Configuration Ethernet adapter Ethernet: Connection-specific DNS Suffix : corp.local IPv4 Address. . . . . . . . . . : 192.168.10.45 Subnet Mask . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . : 192.168.10.1​ Full Details To view additional fields such as DHCP server, DNS, and adapter description: ipconfig /all Sample Output Windows IP Configuration Host Name . . . . . . . . . . . : TECHSUPPORT-PC Primary Dns Suffix . . . . . . : corp.local Node Type . . . . . . . . . . . : Hybrid Ethernet adapter Ethernet: Description . . . . . . . . . . : Intel(R) Ethernet Connection I219-LM Physical Address. . . . . . . . : B4-2E-99-01-34-AB DHCP Enabled. . . . . . . . . . : Yes IPv4 Address. . . . . . . . . . : 192.168.10.45(Preferred) Subnet Mask . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . : 192.168.10.1 DHCP Server . . . . . . . . . . : 192.168.10.5 DNS Servers . . . . . . . . . . : 192.168.10.20 192.168.10.21   Graphical Method (Modern Windows) Go to Settings > Network & Internet Select Ethernet or Wi‑Fi Choose the active network View IP settings (IPv4) This section shows IP address, subnet, gateway, DNS, and DHCP/static status. 2. Windows 2000, XP, Vista These systems use the same commands as modern Windows versions: ipconfig ipconfig /all Outputs are similar but may lack newer fields (e.g., IPv6). 3. Windows 95, 98, ME Use the legacy tool WINIPCFG. Go to: Start > Run Type: winipcfg Select the correct adapter from the drop‑down list. Sample Output Windows IP Configuration Adapter Address: 00-80-C8-FB-3E-21 IP Address: 192.168.1.15 Subnet Mask: 255.255.255.0 Default Gateway: 192.168.1.1 DHCP Server: 192.168.1.5 DNS Servers: 192.168.1.20   Additional Troubleshooting Notes for BMS Engineers If the PC displays a 169.254.x.x address, it is not communicating with a DHCP server. For direct connection to an Automation Server: Set the PC to a static IP in the same range as the AS (default AS IP is typically DHCP or user-defined). Verify only the required adapter is enabled (multiple adapters can cause routing conflicts). USB-to-Ethernet adapters often appear with different names—verify you are checking the correct interface.

Issue Guidance is required on correct installation, configuration, and usage of Wireshark to capture and analyse Ethernet or BACnet communications for diagnosing Building Management System (BMS) issues. Product Line Andover Continuum, EcoStruxure Access Expert, EcoStruxure Building Operation, Satchwell BAS & Sigma, Satchwell MicroNet, TAC IA Series, TAC INET, TAC Vista, EcoStruxure Security Expert Environment Ethernet networks BACnet IP or BACnet MS/TP IP‑connected BMS controllers Packet capture and protocol analysis using Wireshark Cause Network or protocol issues require packet-level inspection to diagnose device behaviour, communication failures, timing issues, protocol errors, or unexpected traffic patterns. Resolution 1. Downloading and Installing Wireshark Download the latest version from: https://www.wireshark.org If using a zipped installer, extract and run the executable. Follow the installer prompts to complete installation. 2. Rules and Best Practices for Capturing Network Traffic 2.1 WHERE to Capture (Critical for Accuracy) Capture traffic as close as possible to the device exhibiting the issue. If the issue is at a controller, capture directly on that controller’s port (IP or MS/TP). If analysing interactions between multiple devices (Enterprise Server, Automation Server, JACE, HVAC plant), capture at the device performing the BACnet client/server role. Placement matters; think of it like placing a microphone in the correct location to capture the right sound. 2.2 HOW to Capture Ethernet / IP captures Use one of the following: Network Tap (e.g. SharkTap,) Managed Switch with Port Mirroring enabled (see How to Configure a NETGEAR Prosafe Plus Switch for Mirroring.) Avoid: Unmanaged switches Managed switches without mirroring These will filter unicast traffic, preventing Wireshark from seeing controller‑to‑device communications. Port mirroring configuration must: Mirror all inbound and outbound traffic for the controller interface Apply zero filtering BACnet MS/TP captures To capture MS/TP: Use a RS‑485 adapter Connect directly to the MS/TP trunk Ensure correct polarity and bus loading Refer to Capture BACnet MS/TP Traffic 2.3 WHAT to Look For When Capturing Verify you can see: Broadcast packets Packets to and from the target device’s IP address Use filters such as: bacnet bacapp bvlc ip.addr == <device_IP> 2.4 WHEN to Capture Start capturing before the issue occurs. If waiting for an intermittent condition (e.g. generator test, network reconvergence, power cycle), use: Capture ring buffer Continuous rolling captures Document: Exact times events occurred Steps used to reproduce Any observed symptoms This allows correlation between traces and known events. Reference: Wireshark Capture Ring Buffer 3. Preparing Before Analysis To ensure meaningful analysis, collect the following: 3.1 System Documentation Network architecture diagrams Switches and routers involved VLANs, port configuration, any LACP/RSTP involvement IP addresses and MAC addresses for all relevant devices BACnet device instance IDs, object types, object IDs 3.2 Event and Operations Data Process steps or operations performed (with timestamps) What was happening at the moment of failure or anomaly Any manual actions triggered by the operator 3.3 Protocol Understanding Issues may originate at lower OSI layers than expected. Be familiar with: ARP DHCP NTP SNMP SMTP RSTP UDP / TCP BACnet (IP + MS/TP) BACnet Behaviour to Consider COV subscription renewal on device restart Typical COV notification frequency (no more than ~4/min per object) Time Sync timing (EBO and Continuum: hourly, at xx:38) Write-on-change behaviours Decoding BACnet errors 4. Capturing Traffic with Wireshark Open Wireshark Select Capture → Interfaces Identify the correct NIC (via IP address or packet counter) Click Start Reproduce or wait for the issue Click Capture → Stop Save capture via File → Save As 5. Starting Analysis in Wireshark 5.1 Validate the Capture Check Statistics → Capture File Properties (Confirm time window covers the incident) Check Analyze → Expert Information (Warnings, malformed packets, error counters) 5.2 Apply Appropriate Filters Examples: bacnet bvlc bacapp.service == readproperty eth.addr == <MAC> ip.addr == <IP> For BACnet, refer to the Wireshark Profiles: BACnet EBO forum post 5.3 Analyse Against the Problem Statement Compare packet activity to expected behaviour Examine frequencies (COV, Time Sync, I-Am, Who-Is) Identify delays, retries, rejected messages, or malformed frames Correlate timestamps with known events

Issue Need to mirror a switch port on a NETGEAR ProSafe Plus switch to capture controller network traffic using Wireshark. Product Line Andover Continuum, EcoStruxure Access Expert, EcoStruxure Building Operation, TAC IA Series, TAC INET, TAC Vista Environment NETGEAR Prosafe Plus Switch Packet capture tools (for example: Wireshark) Cause A mirrored port is required because switches only forward traffic to the destination device’s port. A laptop connected to another port cannot see controller communications. Mirroring creates a copy of packets from the source port and sends them to a dedicated monitoring port, allowing Wireshark to capture actual controller traffic for diagnosing BACnet, Modbus, or general communication issues. This provides full visibility without interfering with network operation. Note: From EBO 2024 (V6.0) and later, AS‑P and other EBO servers include a native packet capture feature that records BACnet/IP and BACnet MS/TP messages visible to the server. This reduces the need for external port mirroring when troubleshooting BACnet traffic. Resolution Access the switch through the ProSafe Plus Utility or the web interface. Navigate to the Port Mirroring configuration page. Select the controller‑connected port as the Source (Tx/Rx/Both). Select an unused port for the laptop as the Destination. Apply and save the configuration. Connect the laptop to the destination port and begin capturing with Wireshark. Refer to the attached video or the original Area360 post for detailed instructions.

Issue The network interface card (NIC) on a PC is not functioning or is suspected to be faulty. Product Line Andover Continuum, EcoStruxure Access Expert, EcoStruxure Building Operation, EcoStruxure Security Expert, Satchwell BAS & Sigma, Satchwell MicroNet, TAC IA Series, TAC INET, TAC Vista Environment Windows PC Network Interface Card (NIC) Cause A NIC may fail to operate correctly due to: Missing or incorrect network drivers Disabled network interface Physical disconnection Hardware damage Misconfigured TCP/IP protocol stack Resolution 1. Identify the Network Interface Open Command Prompt. Run: ipconfig Review the list of network interfaces and locate the NIC by its adapter name. Record the assigned IP address (if present). 2. Check Physical and Driver Status If the NIC shows as Media Disconnected, plug in a network cable and re-run ipconfig . If the NIC does not appear in the ipconfig output: Open Device Manager and confirm the NIC is listed. If missing, install or update the correct drivers. If present but disabled, go to Control Panel > Network Connections, right‑click the adapter, and select Enable. 3. Determine if the NIC Is Responding Once the NIC has a valid IP address: Open Command Prompt. Ping the NIC’s own IP address: ping <NIC_IP_Address> A functional NIC should return 4 successful replies and associated ping statistics. 4. Verify TCP/IP Stack Functionality Before pinging the NIC IP, you can check baseline TCP/IP operation: ping 127.0.0.1 This tests the local TCP/IP stack only. A successful reply indicates that the protocol stack is operational, although it does not confirm NIC functionality. 5. Determine if the NIC Is Faulty If: The NIC never appears in ipconfig , The device is not detected even with correct drivers, or The adapter cannot be enabled… …it is likely the NIC hardware is damaged and requires replacement.

Issue Customers or internal stakeholders request information about upcoming features or planned enhancements for Schneider Electric Building Automation product lines. Product Line EcoStruxure Access Expert, EcoStruxure Building Operation, EcoStruxure Security Expert, Field Devices, TAC IA Series Environment All current product ranges Cause Product roadmap information is no longer published and requires direct engagement with Product Management. Resolution Roadmap and future‑planning information must be requested directly from the appropriate regional Product Management team. Use the following contacts based on your region: Americas: Americas.EcoStruxureBuilding@schneider-electric.com EMEA: EMEA.EcoStruxureBuilding@schneider-electric.com Asia Pacific & India: AsiaPac.EcoStruxureBuilding@schneider-electric.com Product Managers can provide the most current roadmap content and guidance subject to Schneider Electric confidentiality and release policies. 

Issue Explanation of how Domain Name System (DNS) works and what occurs when a hostname cannot be resolved in a building automation environment. Product Line Andover Continuum, EcoStruxure Access Expert, EcoStruxure Building Operation, EcoStruxure Security Expert, Satchwell BAS & Sigma, Satchwell MicroNet, TAC IA Series, TAC INET, TAC Vista Environment TCP/IP networks supporting Building Management Systems (BMS) Cause Users may require an understanding of how DNS functions, how hostnames are translated into IP addresses, and what causes DNS lookup failures in automation networks. Resolution How DNS Works DNS is a hierarchical, distributed naming service that translates human‑readable domain names into numerical IP addresses required for network communication. There is no single central database; instead, DNS information is spread across multiple DNS servers arranged in a global hierarchy. When a client queries a hostname: The resolver checks local DNS cache If not found, it queries the configured DNS server That server may consult other DNS servers up the hierarchy The process continues until an authoritative answer is found The returned IP address is used for communication Example: www.example.com → 198.105.232.4 This translation is required because while domain names are easier for users to remember, underlying systems communicate using IP addresses. What Happens When a Name Cannot Be Resolved If DNS cannot successfully translate a hostname, the failure results in one of the following conditions: 1. NXDOMAIN – Non-Existent Domain Occurs when DNS determines that the name does not exist anywhere in the DNS hierarchy. Outcome: Client receives "Host not found" or "Domain does not exist" Communication using that hostname fails immediately 2. SERVFAIL – DNS Server Error Occurs when DNS servers are reachable but unable to respond correctly, often due to: Server misconfiguration Firewall blocking Server outage Outcome: Lookup retries occur Client eventually times out Applications may experience slow response or delays 3. Timeout – No Response Occurs when DNS servers are unreachable or do not answer. Outcome: Resolver waits for retry intervals Secondary DNS may be queried Final result is a timeout error Impact in Building Automation Systems Failure to resolve hostnames can result in: Automation Servers failing to reach the Enterprise Server Cloud services (EBO cloud connectors, remote notifications, licensing endpoints) becoming unreachable Time sync failure when using NTP via FQDN Email notification failures when using the server's hostname name such as smtp.gmail.com BACnet, Modbus TCP, or integration gateways failing if hostname references are used WebStation or client logins slowing due to DNS lookup delays Proper DNS configuration is essential for reliable communication across all Schneider Electric Building Management platforms.

Issue When diagnosing application hangs, crashes, sluggish system behaviour, or installation issues, Product Support may request Windows Event Logs. While the export process is similar across Windows versions, Windows 11 introduces changes to Security log permissions and some Application and Services log channels, which may affect the ability to export or forward specific logs. Product Line Andover Continuum, EcoStruxure Building Operation, Satchwell BAS & Sigma, Satchwell MicroNet, TAC IA Series, TAC INET, TAC Vista, EcoStruxure Security Expert, EcoStruxure Access Expert Environment Windows Operating Systems Cause Windows Event Logs capture critical diagnostic information across Application, System, and Security categories. These logs provide insight into system state, application behavior, and security‑related events. Although Windows 11 retains the same log categories found in earlier versions, Microsoft has modified the access rights and forwarding behavior of certain logs, particularly the Security and Windows Defender Operational channels. This means some logs may not export or forward as they did in Windows 10, even when GPOs and permissions appear correct. Resolution 1. Opening Event Viewer Event Viewer can be opened using any of the following methods: Press Windows + R, type eventvwr, press Enter Search for Event Viewer from the Start menu Open Control Panel → Windows Tools → Event Viewer 2. Logs Required by Product Support Support generally requires the following logs: Application Security System (Located under Windows Logs) If the case involves Security Expert: Security Expert logs located under Applications and Services Logs → Schneider Electric → Security Expert 3. Exporting Logs For each log: Select the log Go to the Action menu Select Save All Events As Choose a filename and save location On non‑English systems, ensure Display information for these languages includes English (United States) 4. Windows 11–Specific Considerations 4.1 Security Log Behavior Changes Windows 11 introduces changes to how the Security log applies access permissions. After upgrading from Windows 10, users may see: Security logs failing to forward to collectors Permissions appearing correct in policy but not being applied Inconsistent behavior when checking effective channel permissions These issues are due to changes in how Windows 11 enforces access to protected channels and are not caused by misconfiguration. 4.2 Application and Services Logs (e.g., Windows Defender) Certain logs in Windows 11 may not export or forward as expected. For example: Some logs, such as Sysmon, continue to function normally Others, such as Windows Defender Operational logs, may fail to forward or export even with correct SDDL and GPO settings Windows 11 applies additional restrictions on some channels that did not exist in Windows 10. 4.3 Event Forwarding Configuration Is Still the Same The underlying steps for configuring Windows Event Forwarding (WEF) remain unchanged in Windows 11: Enabling the Windows Event Collector service Configuring WinRM Using source‑initiated or collector‑initiated subscriptions Only the behavior of certain logs has changed, not the event forwarding mechanism.

Issue How to capture clear, reproducible steps for troubleshooting or documenting user actions when supporting Building Management Systems Product Line Andover Continuum, EcoStruxure Building Operation, EcoStruxure Access Expert, EcoStruxure Security Expert, Satchwell MicroNet, Satchwell Sigma, TAC IA Series, TAC INET, TAC Vista Environment Windows 7 Windows 10 Windows Server 2008, 2012, 2016 Windows 11 (including versions where PSR is deprecated Cause PSR has historically been used to record screenshots and step-by-step annotated actions to assist support teams in reproducing issues. Microsoft has deprecated PSR in Windows 11 and is transitioning users to more modern built-in tools. PSR remains available in older Windows versions, but is being phased out and will be removed in future releases. Resolution Using PSR on Windows 7, Windows 10, Server OS, and early Windows 11 Open the Start Menu. Type PSR and launch Problem Steps Recorder. Select Start Record. Perform the actions to reproduce the problem. Select Stop Record. Save the generated .zip file. The archive contains an .mht file that can be opened in any browser. The report includes sequential screenshots and a text log of user interactions. PSR continues to function on Windows versions prior to the February 2024 Windows 11 update, even though it displays a deprecation banner on newer builds. Windows 11 and Later: PSR Deprecation and Recommended Alternatives Microsoft introduced a deprecation banner in February 2024. PSR is still present but no longer updated, and will be fully removed in a future Windows release. For BMS support workflows, where clarity and reproducibility are important, the recommended alternatives are: 1. Snipping Tool (Windows 11 built‑in) A modern, integrated tool with screen recording capability introduced in 2023. Allows selection of a specific region to record Produces lightweight MP4 recordings Suitable for capturing short, clear reproduction sequences Ships with Windows 11; can also be downloaded from the Microsoft Store 2. Microsoft Clipchamp A built-in Windows 11 video editor that also includes screen recording. Enables recording of entire screen or application windows Useful for longer or more complex demonstrations Included with Windows 11 or available via the Microsoft Store

Issue Technicians require a clear reference for essential Windows IP troubleshooting commands, including typical outputs and examples to help interpret network behaviour. Product Line Andover Continuum, EcoStruxure Access Expert, EcoStruxure Building Operation, EcoStruxure Security Expert, Satchwell BAS & Sigma, Satchwell MicroNet, TAC IA Series, TAC INET, TAC Vista Environment Windows PC connected to an IP network Building management devices, including: EcoStruxure Building Operation servers and controllers Loytec L‑IP routers iLon routers General IP‑based automation devices Cause During network or BMS troubleshooting, technicians need to validate connectivity, confirm addressing, and identify routing paths. Without examples, command outputs can be misunderstood, slowing down diagnostics. Resolution Accessing the Command Prompt Press Win + R Type cmd Press Enter 1) ping – Test reachability and response time Command ping <IP_or_Hostname> Typical successful response Pinging 192.168.1.50 with 32 bytes of data: Reply from 192.168.1.50: bytes=32 time=2ms TTL=64 Reply from 192.168.1.50: bytes=32 time=3ms TTL=64 Reply from 192.168.1.50: bytes=32 time=2ms TTL=64 Reply from 192.168.1.50: bytes=32 time=3ms TTL=64 Ping statistics for 192.168.1.50: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss) Device offline / not responding Request timed out. Request timed out. Request timed out. Request timed out. Routing/subnet error Reply from 192.168.1.1: Destination host unreachable. 2) ipconfig – View local IP settings Commands ipconfig ipconfig /all Typical brief output Windows IP Configuration Ethernet adapter Ethernet: IPv4 Address. . . . . . . . . . . : 192.168.1.20 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.1.1 Typical detailed output Ethernet adapter Ethernet: Description . . . . . . . . . . . : Intel(R) Ethernet Connection Physical Address. . . . . . . . . : 00-1A-2B-3C-4D-5E DHCP Enabled. . . . . . . . . . . : Yes IPv4 Address. . . . . . . . . . . : 192.168.1.20 (Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.1.1 DNS Servers . . . . . . . . . . . : 192.168.1.10 3) tracert – Identify the route packets take Command tracert <IP_or_Hostname> Typical LAN trace Tracing route to 192.168.1.50 1 <1 ms <1 ms <1 ms 192.168.1.1 2 2 ms 2 ms 2 ms 192.168.1.50 Trace complete. Trace involving NAT/firewall (useful for L‑IP / iLon scenarios) Tracing route to 10.64.20.15 1 1 ms 1 ms 1 ms 192.168.1.1 2 5 ms 5 ms 6 ms 203.10.55.88 <-- NAT IP the device sees 3 12 ms 11 ms 12 ms 10.64.20.15 Trace complete. The second hop (NAT/public address) is often the IP presented to upstream systems and may need to be used in LNS server configuration. How to See Help for Any Command Windows provides quick built‑in guidance for all command‑line utilities. Use the standard help switch: <command> /? Examples: ping /? ipconfig /? tracert /? This displays all command options, parameters, and examples. Capturing Command Output (for Escalation) When opening a support case, attach the raw outputs of: ipconfig /all ping <IP_or_Hostname> tracert <IP_or_Hostname> Option A — Save everything into one file (recommended) ipconfig /all > "%USERPROFILE%\Desktop\network_info.txt" echo. >> "%USERPROFILE%\Desktop\network_info.txt" echo ===== PING 192.168.1.50 ===== >> "%USERPROFILE%\Desktop\network_info.txt" ping 192.168.1.50 >> "%USERPROFILE%\Desktop\network_info.txt" echo. >> "%USERPROFILE%\Desktop\network_info.txt" echo ===== TRACERT 192.168.1.50 ===== >> "%USERPROFILE%\Desktop\network_info.txt" tracert 192.168.1.50 >> "%USERPROFILE%\Desktop\network_info.txt" This creates one Desktop file ( network_info.txt ) containing all three outputs with clear separators. Tip: >> appends to a file; > overwrites a file. Option B — Separate files per command ipconfig /all > "%USERPROFILE%\Desktop\ipconfig_all.txt" ping 192.168.1.50 > "%USERPROFILE%\Desktop\ping_192.168.1.50.txt" tracert 192.168.1.50 > "%USERPROFILE%\Desktop\tracert_192.168.1.50.txt" Option C — Copy output to clipboard ipconfig /all | clip ping 192.168.1.50 | clip tracert 192.168.1.50 | clip After running, press Ctrl+V to paste into a ticket or email. clip.exe is built into Windows. Option D — Manual copy (no files) Run the command. Right‑click Command Prompt title bar → Edit → Mark. Drag to select the text → press Enter to copy. Paste into your case or a text file. Good practice for escalations Label outputs with target IP/hostname and date/time captured. For intermittent issues, capture a longer sample: ping -n 50 192.168.1.50 >> "%USERPROFILE%\Desktop\network_info.txt"   Include your PC IP, subnet, default gateway from ipconfig /all , the device IP, and a brief network path (e.g., VLANs, firewall/NAT present). Additional Troubleshooting Tips If ping fails but ipconfig looks correct, check cabling, switch port, VLAN membership, or firewall rules. Destination host unreachable typically indicates subnetting or routing issues. If the first hop in tracert is unexpected, check default gateway/DHCP settings or adapter priority.

Issue When adjusting the Elevator Relay Time in the elevator reader, the option to save appears, but the setting does not persist. Product Line EcoStruxure Access Expert Environment Access Expert Hosted V3 Mercury MP1502 controller (version 08-2.4.0.653) OSDP Reader Cause The Access Expert Client has an issue with saving individual elevator relay time settings. Resolution Workaround: Navigate to Instance Settings and set the relay time globally. This applies the same relay time to all readers; individual reader settings cannot be saved until the underlying issue is resolved. Additional Notes: Client version: 25.9.26 Controller version: 08-2.4.0.653 A permanent fix will be provided in a future release.

Issue SAFR Face Scan successfully detects faces but does not authenticate users or grant access.        Product Line EcoStruxure Access Expert Environment Access Expert Hosted V3 SAFR Scan Reader using OSDP Cause The default SAFR Scanner Access Feedback Timeout is set to 300 ms, which is too short for proper authentication. In some cases, physical impact during transit may also require light sensor recalibration. Resolution   Access the SAFR Scanner configuration web page and log in. Navigate to System > OSDP settings. Change the Access Feedback Timeout from 300 ms to 1000 ms and click Apply. Test authentication. If issues persist: Perform light sensor calibration (refer to SAFR documentation). SAFR portal: https://safr.com/safr-portal/ (login required)

Issue After installing and configuring the LP4502 (online) and downstream devices per the Installation instructions, KGC devices remain offline. (See highlighted snapshot below) Link to Kone Integration Instructions: Access Expert Kone Elevator Integration  Product Line EcoStruxure Access Expert Environment Access Expert Hosted V3 Kone Elevator Integration LP4502 Comm2 with Micro-B USB adapter (Pluggable USB2-OTGE100) Cause Using the LP4502 comm2 port with a Micro-B USB adapter for elevator communication on a separate subnet is NOT supported. Note: Other Elevator integrations (Thyssen Krupp, Otis) support this setup, which can cause confusion. Resolution 1. Use Comm1 for LP4502 to connect to the internet and site instance. 2. Ensure LP4502 and Kone elevator equipment are on the same subnet. 3. Configure site IT switch: Block internet-to-Kone communication. Allow local traffic on port 2005. KGC downstream IPs must communicate with the LP4502 primary NIC IP. Once completed, the LP4502 and the KGC downstreams will come online and will communicate with the Kone Elevator equipment. Summary KGC downstream devices fail to come online when LP4502 is configured using Comm2 with a Micro-B USB adapter. This setup is not supported for Kone Elevator integration.  

Issue Information is needed about the Access Expert Kone Elevator Integration Product Line EcoStruxure Access Expert Environment Access Expert Hosted V3 Cause Kona Elevator integration information  Resolution Overview: Destination Dispatch is a licensed feature for Access Expert and used when customers are modernizing their elevator systems or deploying newer ones which do not utilize the relay-based approach for floor control and selection. Within Access Expert, 3 different elevator platforms are supported which include Otis, Kone and ThyssenKrupp. For this document, we will focus on a KONE deployment. It is important to note that a single Access Expert can support multiple integrations at the same time. The KONE integration supports up to 128 total floors of control. When using front and rear entry points within the elevator cabs), each entry point is considered a separate destination. This means a 32- story building using front and rear entry points will result in 64 individual destinations.   A KONE protocol was created so that the LP controllers can manage access for the KONE Elevator Group Controller. Mercury will support configuration for Destination Operation Panels (DOPs), Car Operation Panels (COPs), and turnstiles. This feature is supported on the LP4502, and EP4502. The support for KONE Elevators was added in firmware 1.25.5.   Prerequisites: 1. Access Expert System 2. KONE Destination Dispatch License - FN-DEST-KONERS 3. Appropriate Reader Licenses 4. AX-LP4502 5. Coordination with the Elevator Contractor A KONE Elevator Destination Dispatching System mode was created within Access Expert so that the LP4502 intelligent controller can inform a KONE DEC (Destination Entry Computer, E.g. touch screen or keypad) allowed and authorized floors for a cardholder. This feature is only supported on the LP4502. Note: Other Elevator Destination Dispatch integrations i.e. Thyssen Krupp and Otis use the 2 nd port on the LP4502 controller to communicate with the elevator equipment on a separate subnet. ** The Kone Destination Dispatch integration does NOT support using the 2 nd comm port on the LP4502 to communicate with the Kone elevator equipment. If you attempt to do this, you will be unable to connect to the KGCs, and they will not come online. If you use the Kone elevator simulator for testing, there will not be any response from the KGCs even though you can ping the IP addresses.   Controller Page 1. On the LP4502 controller page, navigate to the "Destination Dispatch" Tab. 2. Select Kone. 3. Enable "Has front and rear floors" if your Kone setup has front and rear floors. Make sure to take into consideration this flag when assigning elevator floors access. It is also recommended to consider the door when creating names. Examples like 2F or 2R are beneficial to system operators. 4. Set the Maximum Cabin Configurations. This is the number of Kone Cabin Access configurations that can be stored on the controller. 5. Press Save. 6. From the "Add Downstream" dropdown, select Kone KGC under the network port. 7. Enter the Display Name to be applied to be used.  8. Enter the KONE primary KGC IP address and Port. 9. Leave 2005 as the default port number. Press Save 10. Repeat steps 6 to 8 for the Backup KGC. 11. Issue a "Push Controller Database" command.   Reader Page Once the Interface Controller has been saved, add/Navigate to a reader attached to the Controller, and move to the elevator tab. The Reader does not reside on the KONE KGC downstream. The KGC downstream is only used to configure the controller with the Primary/Backup KGCs. The readers must be on the regular Mercury downstream modules or attached to the LP4502. Because of this, the actual reader setup is similar to a regular door/elevator deployment with the addition of new settings on the Elevator Tab. Once the Elevator Type is set to Destination Dispatch, a series of settings will be enabled and displayed. You will be presented with a WARNING Message when the Elevator Type is selected. This message is normal and you should select YES. 1. On the reader page, navigate to the "Elevator" tab. 2. Select "Kone Destination Dispatching" as the Elevator Type. 3. Select the Kone Operation Type. Please note that Kone does not support mixing Remote Call Giving Interface (RCGIF or turnstiles) with Destination Operation Panel (DOP) and/or Car Operation Panel (COP). Only one is supported at a time. 4. Depending on the Operation Type, specify the fields. 5. If desired, select an Override Elevator Access Level. This will allow a set of floors to be public during defined schedules. 6. Press Save. Kone Cabin Access Page 1. Navigate to "Access Configuration" on the Main Ribbon bar. 2. Go to "Kone Cabin Access". 3. Click on "Add Kone Cabin Access". 4. Enter a Display Name. 5. Enter the allowed cabins (up to 255). You can use the following formats to enter values: 1-10,15,16. 6. Press Save. Person Page Once the reader has been saved navigate to the person(s) who you want to grant access to the destination dispatch and select the new destination dispatch tab at the bottom of the page this will take you to a new Destination dispatch tab. To add an Elevator user setting, simply select the elevator type you wish to grant access to and click the add button. You will be prompted to select a controller. If there are no active LP4502 elevator controllers, then the dropdown will be empty meaning the user needs to add a valid controller. 1. On the person page, navigate to the "Destination Dispatch Settings" tab. 2. On the "Kone Settings" tab, click on "Add Kone Setting". 3. Select the Kone controller and press OK. 4. Enter the Default Floor. 5. Enter the Default Floor Side. 6. Select a Cabin Access 7. Select the Kone Elevator flags to be applied to the person. 8. Press Save.  *Users must configure the Instance Settings to reflect the correct number of floors. The Cab used will be sent by the Kone system to Keep on an 'Access Granted' and displayed in event data. Masks Kone has Global and Specific Masks that are used when setting schedules. These can be set and cleared by right-clicking on the controller and selecting the appropriate option. Setting the Global Mask opens the Global Mask Configuration window. To add a floor configuration, click the "Add Floor Configuration" button, then select the desired floors. From there the options for each floor can be selected by setting the appropriate flags for the floor. Click "OK" to save the changes. Other Information: Each Elevator Manufacturer has specific settings, commands or fields when deploying the Destination Dispatch integration. The following are specific to KONE: Supported Reader Types: 1. Destination Operation Panel (DOP) – Destination operation panels are located outside of the elevator car. Each of these will be configured as a separate reader. 2. Car Operation Panel (COP) – Destination operation panels are located inside the elevator cab. Each of these will be configured as a separate reader. 3. Turnstile (RCGIF) – Turnstiles are half-height sensor barrier solutions designed for public and commercial buildings and airports. Each turnstile will be configured as a reader and must use a Mercury reader port.

Issue Guidance is needed to enable reading of PIV (FIPS-201) cards using the AX-SSC controller and AC1 downstream devices within EcoStruxure Access Expert. Product Line EcoStruxure Access Expert Environment AX-SSC Cause Sites migrating from Continuum systems require a clear, step-by-step process to ensure PIV cards are properly enrolled and recognized in Access Expert. Resolution What is FASC-N? FASC-N stands for Federal Agency Smart Credential Number. It is a 25-byte (200-bit) identifier embedded in PIV cards, used to uniquely identify the cardholder across federal systems. It is composed of multiple fields, including: Agency Code System Code Credential Number Credential Series Credential Issue Person Identifier Organizational Category Organizational ID Person Org Association These fields are encoded using Packed Binary Coded Decimal (BCD) with odd parity, and together form a unique string used by access control systems to authenticate users. Understanding the FASC-N Structure In the Continuum Personnel object below, the fields highlighted are those that make up the FASC-N The PIV enrollment tool generates a character string when a card is presented. For example: 32013733334894141152472674132011 This string is composed of the following FASC-N fields: Field Value Agency Code 3201 System Code 3733 Credential Number 334894 Credential Series 1 Credential Issue 4 Person Identifier 1152472674 Organizational Category 1 Organizational ID 3201 Person Org Association 1 Note: If no enrollment tool is available, manually concatenate these fields in the order shown to create the FASC-N string. Configuration Steps 1. Card Format Setup Configure the card format in Access Expert as follows: Card Format Type: Standard Bit Length: 128 Large Encoded Card Number: ✅ Checked Convert 200 FASCN Bit to 128 Bit: ✅ Checked Card Number Starting Bit: 0 Card Number Bit Length: 128 2. AX-SSC Controller Configuration Ensure Enable Large Encoded Card Number is checked. Assign the card format created in Step 1 to the controller. 3. Person Object Configuration Navigate to Add Card Assignments. Paste the full FASC-N string into the Display Card Number field. This will auto-populate the Encoded Card Number field. Since the Encoded Card Number field is limited to 16 characters, truncate the string from the end until only 16 characters remain. Paste the full FASC-N string into the Hex Value field. ⚠️ Although labeled "Hex Value", enter the string as decimal digits. Save the Person object. Additional Notes Only the editors mentioned above require configuration for PIV card support. Editors such as Reader, Access Level, etc., do not need special configuration for PIV cards.

Issue How is a subnet defined, and what role does it play in IP networking? Product Line EcoStruxure Access Expert, EcoStruxure Building Operation, EcoStruxure Security Expert, TAC I/NET Environment This explanation is based on principles outlined in TCP/IP Network Administration by Craig Hunt, published by O’Reilly & Associates, Inc Cause Subnetting is a method used to divide a larger IP network into smaller, more manageable segments called subnets. This segmentation helps optimize IP address usage, improve routing efficiency, and enhance network security and organization. Resolution What Is a Subnet? A subnet (short for subnetwork) is a logical subdivision of an IP network. It is defined by applying a subnet mask to an IP address, which determines how the address is split into: Network portion – identifies the specific network. Host portion – identifies individual devices (hosts) within that network. How Subnet Masks Work A subnet mask is a 32-bit binary pattern that accompanies an IP address. It uses binary values to indicate which part of the IP address refers to the network and which part refers to the host: A bit set to 1 in the subnet mask means the corresponding bit in the IP address is part of the network. A bit set to 0 means the corresponding bit is part of the host. Example IP Address: 192.168.1.10 Subnet Mask: 255.255.255.0 (binary: 11111111.11111111.11111111.00000000 ) CIDR Notation: /24 This means: Network Address: 192.168.1.0 Broadcast Address: 192.168.1.255 Usable Host Range: 192.168.1.1 to 192.168.1.254 CIDR Notation Modern networks often use CIDR (Classless Inter-Domain Routing) notation to define subnets. CIDR expresses the subnet mask as a suffix (e.g., /24 ), indicating the number of bits used for the network portion. Common CIDR Blocks CIDR  Subnet Mask Hosts per Subnet /30 255.255.255.252 2 usable hosts /24 255.255.255.0 254 usable hosts /16 255.255.0.0 65,534 usable hosts Additional Notes Subnets are local constructs: They are meaningful within the internal network and typically not visible to external networks unless explicitly routed. Subnetting supports hierarchical addressing, which simplifies routing tables and improves scalability. Proper subnetting is essential for network performance, security segmentation, and efficient IP address management.

Issue Where to go to download the Access Expert Device Administrator application. Product Line Access Expert Environment Server 2012 SQL 2012 and above Premise Install V2 Hosted V2 Applet V3 Cause There is no documentation on where to go to download the Device Administrator and how to program the SSC to communicate with the selected application. Resolution The following steps describe where to go and download the software and how to use it to program an SSC: Go to the EcoBuilding Exchange In the search field type Device Administrator Select the Access Expert Device Administrator and download to any location Browse to location and double click execute to run and install the program Accept Agreement and click next to continue installation Click Next to start installing the software Select the location where the file will be installed Successfully loaded software To complete installation, click on Finish Connect the device to a network switch that is open to the internet and launch the application by opening Access Expert device Administrator from the Schneider Electric group in All Programs Launch the application  Right click on the usb line or click on the green arrow to the top left to upgrade the software Once upgraded successfully, Right click again on the line and select properties then select the Ethernet 1 ConfigurationTab Select applicable choice whether it is DHCP or Static addressing being used and click on OK. Once the device comes back Online, select the DIP Switches Tab and check the box for Default User Using the IP address given from step number 13, open up IE and browse to that address Once opened, configure the SSC per Setting up an SSC (System Security Controller), EP1501 and EP1502 Mercury Controllers.