Customer Requests

WIndows Update + Notifications + Restart
We have a requirement regarding the reboot process after critical Windows updates. Our requirement is as follows: When critical Windows updates are installed, the endpoint should notify the user that a restart is required. If the user postpones the restart on the first day, the endpoint should generate another restart notification on the following day. The second notification should not provide the user with an option to postpone the restart. The device should be forcefully restarted after a defined grace period. This is required because some critical Windows updates require a restart to complete firmware/BIOS-related updates and other pending components. Could you please confirm whether this workflow can be configured in Xcitium? If possible, please advise us on the recommended configuration/procedure to achieve the following: Day 1: Notification → User can postpone once Day 2: Mandatory notification → No postpone option → Force reboot Our requirement can be structured like this: Day 1 – Windows update Install all the Windows updates once its completed. Notify the user that a restart is required. Give a short grace period, e.g. 30 minutes. After the grace period, force the reboot. If you specifically need a “user can postpone once” workflow First notification: allow postponement. Record/check whether the endpoint is still in Reboot Pending status. On the following day, run a forced reboot procedure against devices still pending restart. The second notification should use Xcitium's Force the reboot option, rather than the postpone option. Please also let us know if this can be configured through a Patch Management Procedure, Restart Control, or any other Xcitium policy/procedure.
0
·
Xcitium Web Platform
Centralized "Maintenance Mode" / Development Toggle
FEATURE REQUEST: CENTRALIZED "MAINTENANCE MODE" TOGGLE THE PROBLEM Currently, troubleshooting script execution or application behavior is a manual, time-consuming process. Admins must either modify complex profile settings (causing configuration drift) or manually override settings on the local endpoint. This creates a "blind" troubleshooting environment where it is unclear if a failure is due to code errors or Xcitium components like HIPS, Containment, or VirusScope. THE PROPOSED SOLUTION Implement a Global or Per-Endpoint "Maintenance Mode" toggle within the Xcitium Portal. Key Requirements: One-Click Disable: Temporarily pause all protection components for a specific endpoint. Timed Auto-Revert: Set a timer (e.g., 30 or 60 mins) after which protection automatically re-enables. Audit Logging: Log all toggle actions for security compliance. ADVANTAGES BY ROLE FOR CODERS & DEVELOPERS: Instant Validation — Rapidly confirm if a new script or app is being blocked by Xcitium without waiting for profile propagation or digging through logs. FOR SYSTEM ADMINS: Eliminate Config Drift — No more creating "special" permanent profiles or local overrides that lead to inconsistent security across the fleet. FOR MANAGERS & SUPERVISORS: Operational Efficiency — Drastically reduces the "Mean Time to Resolution" (MTTR) for help desk tickets related to software deployment and RDP/connectivity issues. FOR SECURITY OFFICERS: Controlled Risk — A timed toggle is significantly safer than "uninstalling the agent" or "disabling protection indefinitely," which is the current desperate workaround. WHY CURRENT WORKAROUNDS FAIL MANUAL OVERRIDES: Requires remote access to the machine, which is impossible for large distributed teams. PROFILE CHANGES: Far too slow for iterative development or urgent troubleshooting. UNINSTALLING: Leaves the machine completely vulnerable and removes management visibility. SUMMARY FOR PRODUCT TEAM This feature is essential for environments that balance high-security with active development. It turns Xcitium from a "bottleneck" into a "flexible partner" for the IT team. (Ref: Ticket #118257)
0
·
Xcitium Web Platform
Load More