Professional Services Blog

Enabling SSO Authentication for PowerFlow ScienceLogic PowerFlow supports external authentication via Dex, which bridges OpenID Connect (OIDC) Identity Providers (IdPs) like Okta to PowerFlow. This guide outlines configuring Okta as an OIDC IdP, enabling user and group-based login.   Important: All third-party IdP related configurations should be performed by the organization’s Identity and Access Management (IAM) team and must comply with corporate security policies. SaaS Deployments: This article applies to on-premises instances of PowerFlow. For SaaS-hosted PowerFlow, submit a request via the  ScienceLogic Support Portal with your Dex connector config.  Overview This guide walks through the following: Setting up Okta as an OIDC IdP Making Okta’s /default server accessible to Dex Optionally including group claims Configuring the Dex connector Supporting group/non-group logins Testing and Validation Summary Prerequisites   Before beginning, ensure

In complex IT environments, integrations like incident management and Configuration Management Database (CMDB) synchronisation are pivotal. ScienceLogic's PowerFlow platform offers robust capabilities to handle these integrations. However, to ensure optimal performance and prevent resource contention, it's crucial to configure dedicated steprunners and queues for different workloads. This article discusses on-premises instances of PowerFlow. If you are using a SaaS-hosted instance of PowerFlow, please submit a service request via the Support Portal outlining your requirements. The relevant team will then review your request and discuss the necessary changes to be made on your SaaS instance of PowerFlow. Understanding the Challenge Incident management and CMDB synchronisation have distinct characteristics: Incident Management: Typically involves lightweight, high-frequency tasks that require rapid processing to maintain real-time responsiveness. CMDB Synchronisation: Often deals with b

To successfully merge your custom changes into a new PowerPack version, you’ll need to understand how to identify the differences between versions. This process involves: Comparing the original PowerPack version (used to create your custom version) to your customized version – to identify custom changes. Comparing the original PowerPack version to the new ScienceLogic-released version – to identify new features and updates. After understanding these deltas, you can determine whether: The new version already includes features that cover your customizations, or You need to merge and reapply custom changes onto the new version. Let’s walk through the process using an example and then detail the steps to generate and compare PowerPack reports in SL1. Example Scenario Suppose your team customized PowerPack version 112 and named it 112.1. ScienceLogic has since released version 115. To upgrade your custom PowerPack to a new branch (say, 115.1), you’ll need to:✅ Compare 112 vs 112.1 to id

Effective device discovery is a foundational step in building a robust monitoring environment in ScienceLogic SL1. This guide focuses on best practices when performing manual or guided discoveries via the SL1 user interface. For a full overview of the discovery process, refer to the official documentation: 👉 SL1 Discovery Process Documentation Key Best Practices 1. DNS Configuration When discovering devices by hostname, ensure that DNS is properly configured and functional on the collector. Improper DNS settings can prevent successful device resolution and discovery. 2. Use CIDR Notation Thoughtfully If you're using CIDR notation to define the discovery range: Stick with smaller ranges, such as /24, to limit the scope. Large CIDR blocks can overwhelm the discovery process and slow down the collector. 3. Avoid Overloading the Collector Attempting to discover too many devices in one session can lead to performance degradation. A general rule of thumb (on a medium sized collector)

Backing up your ScienceLogic SL1 database is essential for ensuring data integrity and disaster recovery. One effective way to store backups is by setting up a Network File System (NFS) server. NFS allows you to share a directory across multiple machines, making it an ideal solution for centralized SL1 backups. This guide will walk you through the process of installing and configuring an NFS server to store SL1 backups. Step 1: Install the NFS Server Before setting up the NFS server, ensure that your Linux machine has the necessary NFS packages installed. If the nfs-server package is missing, you need to install it. For RHEL, CentOS, Rocky Linux, or AlmaLinux: sudo yum install -y nfs-utils For Ubuntu or Debian: sudo apt update sudo apt install -y nfs-kernel-server After installation, start and enable the NFS service: sudo systemctl start nfs-server sudo systemctl enable nfs-server Verify the NFS server is running: sudo systemctl status nfs-server If it is not running, restart it: su

Enabling SAML-Based SSO in ScienceLogic Global Manager ScienceLogic Global Manager (GM) is a powerful appliance designed to aggregate and display data from multiple SL1 systems, providing a centralized view of your entire infrastructure. Starting with SL1 version 12.2.1, ScienceLogic introduced support for Security Assertion Markup-Language (SAML) based Single Sign-On (SSO), simplifying authentication and enhancing security.   This guide, walks through the process of enabling SAML-based SSO in ScienceLogic Global Manager, so that user access can be managed seamlessly and improve operational efficiency.   Why Enable SAML-Based SSO? Enabling SSO through SAML allows users to log in once and gain access to multiple SL1 systems through the Global Manager providing the users are already authorized to access the target systems. This streamlines Identity and Access Management (IAM), reduces password fatigue, and strengthens the organization's security posture. Getting Started: Bef

How to Effectively Disable Azure VMs in SL1 Using VM Tags When managing resources in a dynamic cloud environment, such as Microsoft Azure, optimizing resource utilization and monitoring is crucial. ScienceLogic’s Azure PowerPack provides an effective way to control Azure Virtual Machines (VMs) using tags. This feature is particularly beneficial for organizations aiming to streamline operations and reduce costs by automating resource management based on predefined rules. What Is VM Tagging? VM tagging in Azure involves assigning metadata to resources in the form of key-value pairs. These tags can help identify, organize, and manage resources based on categories such as environment, department, or project. For example: Key: Environment, Value: Development Key: Owner, Value: IT-Support Tagging becomes a powerful tool when integrated with automation policies to control resource behavior dynamically. How to Add Tags to Azure Virtual Machines Adding tags to Azure VMs is straightforward and

This article assumes you already have a Skylar RCA account. If not, please contact your CSM for a 30-day trial of the product. Step 1: Contact ScienceLogic support to obtain a copy of the OTel collector. Step 2: Install the OTel collector as per installation steps (see the references section below) Step 3: Update the OTel configuration file. This is the otelcol.yaml file in otelcol-sciencelogic-zebrium_x86_64 directory. The following fields will need to be updated Include attribute in filelog block to match the log file location(s) regex in operators > type block. This needs to match the log file format. As a best practice, use a regular expression checker (for example, https://regex101.com/ , to check your regular expression before updating the configuration file endpoint and ze_token sections in the exporters block. These need to be copied from your Skylar RCA instance Step 4: Before sending logs to Skylar, it is recommended configuration is tested with local debugging. This can

Hello Nexus Community Members, Our professional services blog provides expert insights, industry trends, and practical advice to help businesses and professionals navigate challenges and seize opportunities. Stay informed with thought leadership, best practices, and strategies for success. Meet our Bloggers EugeneC Based in Taiwan, Eugene has been a key member of ScienceLogic's Expert Services team within the Professional Services group since June 2019. With a strong background in solution architecture, integrations, and automation, he specializes in designing and implementing scalable, sustainable solutions tailored to customer needs. Eugene has extensive experience with ScienceLogic SL1, PowerFlow, CMDB integrations, ITSM workflows, and event-driven automation. He is also passionate about internal knowledge sharing, customer engagement, and building reusable templates to drive efficiency and innovation. UsmanKhan Usman is a senior consultant in the EMEA Customer Experience team at