Restorepoint Automation PowerPack v104 is Released
Hello, We are pleased to announce that Restorepoint Automation PowerPack version 104 has been released. This PowerPack contains supporting changes to enhance compatibility withRestorepoint SyncPack version 2.3.0. Restorepoint Automation PowerPack version 104 is supported for SL1 v12.1 or higher, and for PowerFlow version 2.6.0 and higher, and works with the Datacenter Advanced Enrichment Actions PowerPack. Thank you, Release ManagementServiceNow Base SyncPack v3.8.1
Hello, We are pleased to announce the release of ServiceNow Base SyncPack version 3.8.1, which is designed to support ServiceNow CMDB SyncPack version 3.6.1, also released today. Features Included in This Release Added updates to support "ServiceNow CMDB" SyncPack version 3.6.1. Thank you, Release ManagementServiceNow CMDB SyncPack v3.6.1
Hello, We are pleased to announce the release of ServiceNow CMDB SyncPack version 3.6.1. Dependency Note: To use this SyncPack, you must also install "ServiceNow Base" SyncPack version 3.8.1 or later with this release. Enhancements and Issues Addressed in This Release The following issues were addressed in this release: Added "cmdb_ci_wap_network" to the customer_ci_relations_overrides configuration option on the "Sync Devices from SL1 to ServiceNow" application. Addressed an issue that caused Device sync mappings to pull directly from the configuration object in PowerFlow. (Case ID: 00447321) Addressed an issue with the "Sync Interfaces from SL1 to ServiceNow" application that caused constant updates if the interface type was included in the mappings. As part of this fix, "type_id" was added to the default mappings, which will not be sent to the "cmdb_ci_network_adapter" or "cmdb_ci_lb_vlan" tables since the field does not exist on those tables in ServiceNow. (Case: 00464089) Made a series of updates to the "Sync Interfaces from SL1 to ServiceNow" application: Made an update to ensure that the interface "object_source_id" matches the CI table destination. For example, an interface which is sent to the "dscy_switchport" table will always have a native key containing "IFSWPort". The enable_advanced_topology toggle is now false by default, which means interface to interface relations are not sent by default. Added a new JSON mapping parameter, interface_advanced_mappings, which allows you to define the mappings for the combination of interface IANA type and parent device type to a specific ServiceNow table. This configuration option is blank by default, and must be configured to define the mappings you want to use. For more information about using this parameter, see the Configuring Additional Syncs for the ServiceNow CMDB SyncPack chapter in the ServiceNow CMDB SyncPack manual. Added a new JSON mapping parameter, interface_relation_mappings, which operates similarly to the relationship overrides in the Device Sync. This parameter allows you to define which interface relationships to send to ServiceNow. This configuration option is blank by default, and must be configured to define the relationships you want to send directly. (Case ID: 00446274) NOTE: If your ServiceNow instance is domain-separated, install the latest "ScienceLogic Domain Separation (Global)" update set in ServiceNow. Ask your ScienceLogic contact for access to this update set. Thank you, Release Management
PowerFlow output to Syslog repository
We're looking at enabling Syslog output to a central repository from PowerFlow at an application level. We've already got this running fine at an OS level and SL1 at an application level. Has anybody setup logging for PowerFlow? We're specifically interested in any login type data and also code changes. I've been through as much doc as I can find on the topic, such as: https://docs.sciencelogic.com/pdf/sciencelogic_powerflow_2-1-1.pdf https://docs.docker.com/engine/logging/drivers/syslog/ https://support.sciencelogic.com/s/article/10819 It doesn't appear straight forward to link log files in /var/log/iservices to their respective Docker services. I'm just looking for validation as much as anything, that Docker level logging of the contentapi and gui processes would be the way forward to capture all relevant security related information, and that all other processes can be ignored.ServiceNow SyncPack Certification Update - Xanadu
Hello all – We are pleased to announce that ScienceLogic's latest integrations with ServiceNow are certified with ServiceNow Xanadu! This is an important milestone, taking place immediately after ServiceNow Xanadu was released. This is exciting news, because Each new ServiceNow release includes valuable features and enhancements that can significantly improve efficiency and functionality. Staying certified ensures our partners can leverage these innovations for their clients. As ServiceNow partners, being certified for the latest release is also crucial, because ServiceNow only maintains the last two releases (n-2). Older releases (more than two versions back) may no longer receive support or updates, making it challenging to troubleshoot issues or implement new features for clients still using outdated versions. As our customers update to the latest with ServiceNow's new releases, we ensure our scoped apps are certified every release to not only be in lock-step but also to leverage new capabilities. With Xanadu, ServiceNow has delivered their “Biggest AI Release Yet!” To learn more, seehttps://www.servicenow.com/community/releases-and-upgrades/ct-p/releases-and-upgrades. Thank you, Release ManagementWho will be our next SL1 Innovators?
Hello Nexus Members, Looking to showcase your creativity, innovation, and inspiration? Look no further. In case you're opted out of email, we just launched our SL Innovators Awards!! Our ScienceLogic Innovators Awards were established to recognize and learn from those nerdy by nature, tech buffs, and visionaries using SL1 in pioneering ways to power a better way to work. Show the Nexus Community something cool and innovative you've been working on to achieve real business outcomes. We want to hear your ideas! Submit your applicationby September 12.
Device configuration "key/value" pairs synchronization to ITSM
With Powerflow most data are pretty easy to sync from SL1 to ITSM/CMDB, in this case ServiceNow. But now we have requirement that we should sync cloud device tags from SL1 to SN. The data from Azure virtual server, using Azure PP, is shown on SL1 like below, multiple key/value rows per device. So those are not easily stored into Attributes. And if I have understood correctly, quite a lot of tags used in cloud. Any ideas how these could be synced with PF into ServiceNow?2024 Customer Success Honoree Award Winners
Any community whether online or in person is a place to share and learn. As leader of Customer Advocacy, my role too encompasses sharing the voice of our customer in many formats in order for our peers to thrive from this knowledge. In case you missed it, we recently launched our ScienceLogic 2024 Customer Success Honorees - an awards program recognizing those who have made significant progress in a specific area, and have been an integral champion for SL1 success. I wanted to share with you these wonderful advocates, our finalists, in the hopes it inspires you to share your stories of success with our new Nexus community! Stay tuned for our upcoming 2024 Innovators Awards, an application-based awards program celebrating and recognizing customers and partners who are leading the charge in digital transformation, operational excellence, innovation, and business impact utilizing SL1 in innovative ways. Applications are opening early June! Read more in our CS HonoreeeBook. Congratulations to each of our 2024 Honorees! 👏💣 If you're interested in telling your SL1 story, please reach out to me, and join our Pathfinders customer advocate program.
