Contents

 

About the document

The forthcoming document aims to provide comprehensive guidance to both 1st level support personnel and administrators regarding the GYTPOL Validator tool. This document will encompass a detailed explanation of diverse configuration files, advanced settings, as well as common issues and errors that may arise during usage.

The initial section will focus on elucidating the configuration files and services essential for the proper functioning of the GYTPOL Validator tool. This will encompass elucidations for both the Server, which constitutes the GYTPOL application backend, and the Client, encompassing the devices responsible for reporting. Notably, post-installation issues for both components will be addressed in this part, offering insights into troubleshooting potential hurdles.

Furthermore, this document is envisioned as an evolving resource that will undergo continuous updates. This means that as GYTPOL Validator tool and its environment evolve, this document will be revised accordingly to reflect the latest insights and solutions.

It's important to note that the most recent iteration of this document, along with other pertinent resources, can always be accessed via our official website: https://gytpol.com/resources. We remain dedicated to equipping you with the most accurate and up-to-date information to ensure the optimal usage and performance of the GYTPOL Validator tool.

Audience

This User Guide is primarily intended for individuals and teams responsible for implementing, managing, and maintaining GYTPOL Validator within their organizations. It caters to both technical and non-technical users, providing clear instructions and explanations for all levels of expertise.

Pre-installation

For proper setup and configuration of the GYTPOL application server, please adhere to the following steps:

1. System Requirements and Architecture: Configure the GYTPOL application server in accordance with the specifications listed in the System Requirements document: https://gytpol.com/resource/system-requirements/. Understand the high-level architecture of GYTPOL from the details provided here: https://gytpol.com/resource/architecture/.

2. Pre-Check Tool: Before proceeding with installation, ensure a smooth process by running the GYTPOL Pre-Check tool, available at: https://gytpol.com/checker. This tool will verify that all necessary settings have been properly configured, guaranteeing that the installation process will work seamlessly.

3. Server Preparation: As part of server preparation, create a dedicated GYTPOL service account. This domain user account should not possess any administrative privileges. This account will be utilized for specific services and tasks, confined to the local GYTPOL server only. Ensure that this service account has the appropriate access rights on the local GYTPOL server as well as on the SQL server (if the installation involves over 3000 clients).

By meticulously following these steps, you'll be on your way to a successful GYTPOL deployment and installation. The proper configuration and preparation of the server environment, combined with the utilization of the Pre-Check tool, will contribute to a streamlined and efficient process during the installation meeting.

Installation

The server installation process for GYTPOL is straightforward and can be completed upon receiving the necessary executables from the GYTPOL team. Here's an overview of the steps involved:

1. Receiving Executables: The GYTPOL team will provide you with the necessary executables for the GYTPOL Server installation.

2. Client Installation Packages: Additionally, client installation packages tailored to your specific requirements for Windows, Linux, and macOS systems will also be provided.

3. Server Installation: Follow the guidelines in the "Server Installation User Manual - GYTPOL" document to carry out the installation process. This comprehensive document will provide you with step-by-step instructions to ensure a successful installation.

4. License Request and Activation: After the installation, proceed to send a license request to the email address: license@gytpol.com. Following this request, you will receive a license key from the GYTPOL team.

5. License Activation and Homepage Access: Load the received license key into the system. Once activated, you can access the GYTPOL homepage. This marks the successful completion of the installation process.

Notably, by default, the GYTPOL installation will set up a localDB, eliminating the need for an external or dedicated SQL server. However, if your deployment encompasses more than 3000 reporting devices, an external SQL server becomes necessary. In this scenario, the database management will be conducted on the external SQL server instead of locally.

By following these steps and adhering to the provided documentation, you can efficiently complete the GYTPOL Server installation and ensure the proper functioning of the GYTPOL system in your environment.

Configuration files and services

The forthcoming section outlines the organizational structure of the GYTPOL working directory, located by default at "c:\gytpol". This directory houses various files, particularly within the Data subfolder. Following the installation of GYTPOL Server, the subsequent folders will be established, containing database files, configuration files, and predefined settings files:

Data Folder: This folder, located within the "gytpol" directory, serves as the repository for crucial files. The following files are situated here:

• Database Files: These files constitute the heart of GYTPOL's data management system.

• Configuration Files: These files hold the system's configuration settings.

• Predefined Settings Files: These files contain predetermined configurations and settings for specific functionalities.

GytpolServer Folder: The "GytpolServer" folder, also positioned within the "gytpol" directory, encompasses a multitude of essential components:

• System Executables: These files are responsible for driving the core functionalities of the GYTPOL system.

• Binaries: This directory houses binary files required for various operations.

• Libraries: Libraries contain essential code resources that contribute to the system's functionality.

 

Two important notes to consider:

1. Elevated Editing: All JSON files mentioned in the following context must be edited using an elevated text editor such as Notepad (run as Administrator) or Notepad++, which will elevate itself when necessary. This practice ensures that the modifications are carried out with the appropriate privileges.

2. Installation Drive Variability: It's important to recognize that the drive designated for software installation might differ, contingent on the Windows Server settings. As a result, the installation drive could be labeled as D drive, E drive, or any other drive letter based on the configuration.

By understanding this directory structure and following the guidelines provided, you can proficiently navigate and manipulate the essential files within the GYTPOL working directory.

Analyzer

Relevant service and DBs

• Data: "gytpol_analyzer.mdf"

• Log: "gytpol_analyzer_log.ldf"

 

All the below files are located in c:\gytpol\data\Analyzer

appsettings.json

The file contains the database connection string and includes critical information about the SQL server name and the database name. Here are a few important points to consider regarding this file:

Connection String Content:

External/Shared SQL Servers and Encryption:

Example of Default LocalDB File:

Config > clientUpgrade.json

GYTPOL features an auto-update functionality for clients, allowing the updating of existing clients to the latest version once the updated version is made accessible on the server. To accomplish this, follow these steps as outlined:

Client Auto-Update Steps: Detailed steps for the auto-updating of GYTPOL clients are provided at: https://gytpol.com/resource/client-update-manual/.

 

The file managing parameters related to GYTPOL client auto-upgrades is the "clientUpgrade.json" file. This file plays a crucial role in managing parameters for the client auto-update process. Here are the fields within this file that you can modify:

 

"computers" Field: The "computers" field manages the list of computers that require updating. The default setting is "all," updating any client reporting to GYTPOL. To update only specific clients, list their names in JSON syntax. Example:

"computers": [

"pc01", "pc02", "srv01", "dc02"

],

 

"links" Field: The "links" field defines the URL from which clients download the new version. Provide the GYTPOL server's FQDN. For Remote Employees, add additional links from web-facing servers. Example:

"links": [

"https://<GYTPOL-SRV-FQDN>:9093/updates/gytpolClient_x64.msi",

"https://<customers-webserver.domain.com>/path-to-msi.msi"

],

"gytpolClient" Field: This field specifies the name of the client file as the end of the URL specified in the "links" section. Update this field accordingly. After the initial upgrade, leave it as is.

 

"version" Field: The "version" field signifies the client file version. You can verify the version by accessing the Details tab. To do this, right-click the client MSI file, select "Properties," and then navigate to the "Details" tab where you can find the version information in the "Subject" field.

 

By understanding and modifying these fields as necessary, you can effectively manage the auto-upgrade process for GYTPOL clients, ensuring that they are always up to date with the latest version and enhancements.

 

Config > SIEM.json

GYTPOL offers the capability to forward data regarding findings, alerts, and remediations to a SIEM (Security Information and Event Management) system using the syslog protocol. This data forwarding is managed through the "siem.json" file, and the process is outlined below:

"host" Field: This field should contain the hostname or IP address of your SIEM server that will receive the data sent by GYTPOL.

 

"port" Field: Specify a port number that is open and available for communication over TCP with your SIEM. Typically, port 514 is used for this purpose.

 

"protocol" Field: Set the protocol to "TCP". UDP is not supported for data forwarding in this context.

 

"gytpolServer" Field: Enter the GYTPOL server's fully qualified domain name (FQDN) to establish the connection between GYTPOL and the SIEM.

 

"isSiemIntegrationEnabled" Field: Change the value of this field to "true" to enable the SIEM integration.

 

Once you've made these changes in the "siem.json" file, it's essential to restart both the "gytpol Data Repository" service and the "gytpol Analyzer" service, as the latter is dependent on the former. This restart ensures that the updated configurations take effect and that the data forwarding to the SIEM is initiated properly.

 

By following these steps, you can seamlessly integrate GYTPOL with your SIEM system, enabling the transmission of pertinent data for analysis and monitoring purposes.

 

Config > options.json

If the GYTPOL support team requires more detailed logs to facilitate troubleshooting or to gain insights into the system's operational status, please follow these steps:

1. Adjust "minLogSeverity" Value: Change the value of "minLogSeverity" from the current setting of 5 to 0. This adjustment will increase the logging verbosity, capturing more detailed information in the log files.

2. Save the Configuration File: Save the changes made to the configuration file.

3. Restart "gytpol Analyzer" Service: To apply the modified logging settings, restart the "gytpol Analyzer" service. This ensures that the new logging configuration takes effect.

4. Review Additional Log Files: Once the service is restarted, additional log files will be generated in the "Analyzer > Config > logs" folder. These log files will contain more comprehensive information about the system's processes and operational status.

 

By following these instructions, you can generate more detailed logs to provide the GYTPOL support team with the necessary insights to assist in resolving any issues or enhancing the system's performance.

 

GPMCProxy

All the below files are located in c:\gytpol\data\GPMCProxy

Relevant service

 

If your architecture involves utilizing a localDB without an external SQL server, it's important to note that the only service that will make use of the "gytpolSVC" account (which was created during the server setup) is the GYTPOL GPMC Proxy service.

config > dcs.json

The mentioned file, which will be automatically populated during GYTPOL installation process, holds a crucial list of Domain Controllers to be utilized by the Policy Validator module and the dsRequester in GYTPOL. It plays a pivotal role in facilitating the operations of these components.

Here are the key points regarding this file:

• Automatic Population: The file will be populated automatically based on the Domain Controllers in the same site as GYTPOL server.

• Blank File Impact: An empty file will result in the Policy Validator module not functioning, causing the associated page to appear blank.

• Modifications in JSON Format: If any changes are made to this JSON file, such as adding or removing Domain Controllers, it's essential to maintain the file's comma-delimited format as demonstrated in the provided example.

• Restarting Services After Changes: Following any adjustments to the JSON file, ensure to restart the following GYTPOL services to enact the changes: "gytpol GPMCPROXY service," "gytpol Data Repository service," and "gytpol Validator service."

•  

By adhering to these guidelines, you can effectively manage the Domain Controllers used by the Policy Validator module and the dsRequester within GYTPOL, ensuring that these components operate optimally and in accordance with your requirements.

 

RsopRepository

Relevant service and DBs

In the context of GYTPOL utilizing a localDB setup, the databases are stored within the "c:\gytpol\data\RsopRepository" folder. This folder contains two essential database files:

• Data: The "gytpol_rsop_reports.mdf" file holds the core data of GYTPOL's RSoP (Resultant Set of Policy) reports.

• Log: The "gytpol_rsop_reports_log.ldf" file is the log file accompanying the data file, tracking changes and maintaining data integrity.

 

Furthermore, it's crucial to note that whenever changes are made to any configuration files within the GYTPOL setup, restarting the relevant GYTPOL services is imperative. This restart ensures that the changes are applied, settings are updated, and the system operates seamlessly based on the modified configurations.

 

All the below files are located in c:\gytpol\data\RSOPRepository

appsettings.json

The file in question contains the database connection string and provides information about the SQL server name and the specific database name. This information is typically located within the file, specifically on line #7.

 

Below is an example of a default localDB database connection string. This example showcases how the connection string is structured:

 

Config > domains.json

The file will encompass a list of domain names that are permitted to undergo the Policy Validation module using the Group Policy Modeling Wizard. These domain names will be subject to a comparison against the actual policies applied to the respective devices or users. The Policy Validation page will then exclusively display devices that are associated with the domains specified within this JSON file.

In essence, this JSON file acts as a filter, ensuring that only devices linked to the approved domains are considered for the Policy Validation process. This targeted approach streamlines the process by narrowing down the focus to specific domains, enhancing the accuracy and relevance of the analysis performed by the Group Policy Modeling Wizard.

 

Config > options.json

Here are two important settings in GYTPOL's configuration that control reporting intervals and logging severity:

1. minMinutesBetweenReports: This parameter sets the minimum time interval between reports sent from the same device. The default value is 150 minutes (2 hours and 30 minutes). While this value can be modified for troubleshooting purposes, it's advised not to lower it significantly. Adjusting this parameter might be useful in situations where you need more frequent reports from specific devices for diagnostic purposes.

2. minLogSeverity: The "minLogSeverity" parameter dictates the level of detail in the logs generated by GYTPOL. By default, it's set to 5. However, if the GYTPOL support team requires more comprehensive logs to troubleshoot issues or gain insights into system operations, you can change this value to 0. This adjustment will increase the level of logging detail. To apply this change, you'll need to restart the "gytpol Data Repository Service" service.

 

As a result of this adjustment, additional log files will be generated in the "RsopRepository > Config > trace" folder. These logs will contain a higher level of information regarding the system's processes and operational status.

 

By understanding and adjusting these settings as needed, you can optimize GYTPOL's reporting intervals and logging detail for effective troubleshooting and monitoring.

 

Config > URLs.json.

Provided is a compilation of internal URLs designated for diverse system components. These URLs play the role of transmitting and receiving data internally among GYTPOL's microservices and databases. It's paramount that these ports remain insulated from external access, designed exclusively for local utilization.

 

We strongly advise against altering the configurations within the file. However, if your operations involve Nutanix hypervisors and port 5000 is engaged by Nutanix processes, we recommend reviewing the port 5000 modification procedure for guidance.

Config > vdiImages.json

The designated file serves as a controller for VDI Pool names within which the GYTPOL client is deployed. When GYTPOL client is installed on non-persistent VDI instances that undergo regular resets, such as weekly or nightly, the client's changes will be reversed, leading to the reemergence of alerts.

 

Upon adding a Pool name to the file, the VDI instances belonging to that Pool will be allocated a dedicated section within the UI. To enable this functionality, the file should contain the specific Pool name. Any VDI instance that aligns with the specified name will be allocated to the corresponding VDI section in the UI.

 

It's important to note that GYTPOL will disregard any numerical values or hyphens ("-") that appear after the Pool name, including the last hyphen and numerical sequences. For instance, if the Pool name is "PA-R111-COMP," any VDI instances named "PA-R111-COMP-01," "PA-R111-COMP-02," or "PA-R111-COMP-03" will be associated with the "PA-R111-COMP" record in the file.

 

This mechanism ensures that VDI instances under the same Pool name are properly managed and categorized within GYTPOL's UI, irrespective of minor numerical or hyphen variations in their names.

 

 

Updates

This service is specifically designed for customers who utilize the Remote Employee (RE) feature and is not obligatory for all users. When the Remote Employee feature is not required or activated, this service can be disabled and stopped. For further insights into the Remote Employee feature, we recommend consulting the High-Level Design (HLD) document, accessible at the following link: https://gytpol.com/resource/architecture/.

Relevant service

The designated service assumes the role of interfacing with the Cloud API, ensuring the retrieval of pending reports from external devices that are unable to transmit misconfiguration reports through the local URL. This mechanism serves as a fallback, enabling these devices to still report their misconfigurations via the Cloud API.

 

It's important to mention that if the feature is not enabled for the customer and the tenant hasn't been created, the corresponding service can be stopped and disabled. By default, the feature is disabled during the POC phase.

If you decide to enable this feature later, follow these steps:

1. Ask GYTPOL for support to create Remote Employees tenant in US/EU region.

2. Create an "updates" folder within the c:\gytpol\data\ directory.

3. Copy the appsettings.json file from the client archive to the newly created "updates" folder.

appsettings.json

"pollInterval": This parameter dictates the duration between consecutive interactions with the Cloud API, fetching any pending reports. The default interval is set at 60 minutes. Should the need arise, this interval can be modified, either reducing it for more frequent checks or extending it for less frequent ones.

"remoteURL": This configuration defines the URL for the Cloud API. This URL can be tailored to be either EU or US based (shown in “region” field), based on the specific requirements of the customer. It's a pivotal setting that directs communication to the designated Cloud API location.

"accessKeyID" and "SecretAccessKey": These entries involves the keys that provides secure access to the Cloud API URL exclusively from the server itself. It's a critical security measure ensuring that only authorized access is granted to the Cloud API.

 

When editing any of these parameters within the configuration files, it's essential to bear in mind that restarting the gytpol Updater service is imperative. This reboot guarantees that the modifications are integrated effectively, ensuring the smooth functioning of the service in alignment with the updated configurations.

 

For customers who do not utilize a Cloud API or operate within closed environments, the designated file will lack any entries for "access keys" values. In such cases, this parameter will remain absent from the configuration.

 

During the initial installation process, it's recommended to substitute this file with the version located within the client zip package provided by the GYTPOL team. This ensures that the file's contents are in alignment with GYTPOL's recommended configuration, tailored to the specific client's needs and circumstances.

 

Validator

Relevant service and DBs

For localDB, the DBs located in c:\gytpol\data\Validator folder:

• Data: gytpol_joblog.mdf, gytpol_profiler.mdf, gytpol_validator.mdf

• Log: gytpol_joblog_log.ldf, gytpol_profiler_log.ldf, gytpol_validator_log.ldf

If one of the settings in any config file is changed, please make sure to restart the service.

 

appsettings.json

1. The file will contain the database connection string, explicitly specifying the SQL server's name and the database's name. This information is located in line #3-#5 of the file.

2. Below is an illustration of the default localDB file as a sample reference. This example is intended to offer a clear understanding of the file's structure and content.

Please ensure to incorporate the appropriate SQL server name and database name in the actual file according to your configuration needs.

 

WebSrv

Relevant service

If one of the settings in any config file is changed, please make sure to restart the service.

Static > Updates folder

Within this folder, you are expected to store the client files (e.g., MSI, PKG) necessary for the automated update procedure, which was elaborated upon in the Analyzer section. The URL specified in the "clientUpgrade.json" file directs to the contents of this folder, facilitating the seamless auto-update process. This organized approach ensures that the correct client files are accessible for updates and contributes to the efficiency of the auto-update mechanism.

 

websrv_config.json

The default settings for the management ports are as follows:

• HTTP Port: 9090

• HTTPS Port: 9093

These ports serve as the default access points for GYTPOL's management interface. However, it's possible to modify these ports for more tailored accessibility. This can be accomplished by designating specific users or IP addresses permitted to access the user interface, facilitated through organizational firewalls.

 

If you opt to alter either of these ports, it's imperative to remember that both the HTTP and HTTPS ports need to be changed simultaneously. While you have the flexibility to select different port numbers, it's essential to avoid ports already in use by GYTPOL's internal processes, as indicated in the RsopRepository > URLs.json configuration. This ensures smooth communication while accommodating your specific port preferences.

 

 

"throttledUrls": This parameter signifies the limit of concurrent reports allowed per second. The default value is set at 50 reports per second. It's strongly recommended not to modify this number unless specifically requested by the GYTPOL team. Any adjustments in this regard should be carried out only under the guidance of GYTPOL's experts. If needed, further troubleshooting steps can be found in the provided resource.

 

"permissions": By default, access to the user interface (UI) is extended to Authenticated Users. The management of roles and permissions is conducted within the UI itself, accessible through the "Roles and Permissions" screen. Users within the designated group gain access to the UI, with their access level aligned to the roles assigned to them. Should no roles be granted, an error message will emerge. If necessary, it's possible to switch the group from Authenticated Users to any security group within the Active Directory. However, it's important to note that mere membership within a group is insufficient; actual access levels are established via the Roles screen. This setup ensures controlled and tailored access to GYTPOL's UI in line with your security requirements.

 

PEM certificate

Additionally, the WebSRV folder is the designated location where the Node.js certificates are stored. These certificates are self-signed and are generated as part of the installation process. If you intend to replace the self-signed certificates with your own custom certificate, comprehensive instructions can be found in this document. This resource outlines the steps required to seamlessly transition to your preferred certificate setup.

Server – post-installation / upgrade issues

Upon the successful installation of the server, the system's operations are set in motion, leading to the accumulation of data from both Group Policy Objects (GPOs) and Active Directory (AD). Subsequent to the deployment of the GYTPOL client across endpoints and servers, followed by the completion of a comprehensive scan, the generated reports are transmitted. Once received, the data undergoes meticulous analysis and is then showcased within the Misconfiguration section of the platform.

 

In the upcoming sections, we will delve into fundamental troubleshooting strategies geared towards resolving prevalent issues that may surface throughout this process. This guidance aims to provide you with the requisite knowledge and skills to adeptly manage and address common challenges encountered during the utilization of the GYTPOL system.

 

Services not running

GYTPOL operates through a total of 6 essential services that collectively ensure the proper functioning of the application. These services are outlined as follows:

Logon as a Service

In the event that you encounter difficulties initiating the GPMC Proxy service, or any other service reliant on the GYTPOL service account, it's important to ensure that the domain user designated for GYTPOL possesses the requisite permissions within the "User Rights Assignment" section, specifically under "Logon as a Service."

Tasks not running

GYTPOL employs a collection of tasks designed to facilitate the maintenance of databases and execute queries aimed at extracting data from Active Directory (AD) and Group Policy Objects (GPOs). These tasks operate under the context of a domain user, established during the server setup and configuration process.

 

The key tasks responsible for executing the queries are as follows:

1. gytpolServer: This task is instrumental in managing routine queries and data extraction from AD and GPOs.

2. gytpolServer Daily: Designed for daily operations, this task ensures consistent data acquisition and querying from AD and GPOs.

3. gytpolServer Weekly: Operating on a weekly basis, this task further contributes to the systematic retrieval of data from AD and GPOs.

 

These tasks play a pivotal role in maintaining the accuracy and comprehensiveness of the data accessible within the GYTPOL system, thereby supporting effective analysis and reporting functionalities.

 

Logon as a Batch

In case you encounter difficulties initiating the gytpolServer task, or any other task within the library, subsequent to installation, it's imperative to verify that the domain user established for GYTPOL possesses the requisite permissions within the "User Rights Assignment" section, specifically under "Logon as a Batch."

 

By ensuring that the appropriate permissions are granted, you can facilitate the seamless execution of tasks within the GYTPOL system. This step plays a pivotal role in maintaining the operational integrity and effectiveness of various tasks within the application.

 

 

Error 2147943712

If you encounter error code 2147943712 within the task history, it's advisable to examine the storage of network credentials under the Security Options. To address this, ensure that the specific setting is configured as "Disabled." This can be verified by following these steps:

1. Navigate to the Security Options within your system settings.

2. Locate the option related to storing network credentials.

3. Confirm that the setting is configured as "Disabled."

 

Tasks not created during server installation

If you find that the three mentioned tasks (gytpolServer, gytpolServer Daily, gytpolServer Weekly) were not generated during the server installation, it's recommended to examine the allowance of network credential storage as explained above. This can be verified through the following steps:

1. Access the Security Options within your system settings.

2. Locate the option related to permitting the storage of network credentials.

3. Ensure that the setting is configured to allow network credential storage.

Can’t see the UI

For more intricate troubleshooting purposes, it's advisable to access the logs from the following locations within the GYTPOL system:

a. C:\gytpol\gytpolServer\WebSrv\WebSrv_service.out.log

b. C:\gytpol\gytpolServer\WebSrv\WebSrv_service.wrapper.log

Retrieving the logs from these directories can provide valuable insights for diagnosing and addressing any advanced issues within the WebSRV component.

Not authorized (webserv_config)

To gain access to the GYTPOL UI, membership in a specific group configured in the "webserv_config.json" file is essential. The following guidelines detail this process:

1. By default, login access is granted to "Authenticated Users."

2. If necessary, any other designated group can be added, replacing "Authenticated Users." Any GYTPOL operators should be members of this group (access level is not a determining factor at this stage).

3. If a user is not part of the configured group, access to the UI will be denied.

4. To regain access to the dashboard, it's vital to include the user in the group designated within the configuration file.

No roles

After successfully adding the user to the appropriate group, it's equally important to assign roles and permissions to the user via the "Roles and Permissions" screen accessed through the gear icon (Settings). Here are the key steps:

1. Locate the gear icon in the UI interface and access the "Settings" section.

2. Within the "Roles and Permissions" screen, assign specific roles and permissions to the added user.

3. It's crucial to ensure that roles are assigned to users. Without defined roles, users will be unable to access the UI and utilize the platform's features.

Services are down

It's important to note that if any of the GYTPOL services is stopped, it will impact the accessibility of the UI. In such cases, an error message will indicate the specific service that is affected. To ensure seamless access to the UI and the proper functioning of the GYTPOL system, it's vital to maintain all GYTPOL services in an active and operational state. Regularly checking and ensuring that all GYTPOL servers are up and running will help prevent any interruptions in accessing the UI and utilizing the system's capabilities.

 

GYTPOL Analyzer:

 

Two important points to keep in mind regarding GYTPOL services:

1. GYTPOL Data Repository Service and Analyzer Service: If the GYTPOL Data Repository service is stopped, it will have a cascading effect on the Analyzer service. The proper functioning of both services is interdependent, so maintaining the Data Repository service's operation is essential to ensure the Analyzer service's functionality.

2. GYTPOL Web UI Service: When the GYTPOL Web UI service is stopped, it results in the UI not loading at all. Unlike some cases where an error message might be displayed, stopping the Web UI service will lead to a complete inability to access the UI without any specific application-related error shown.

 

Please note that GYTPOL License Service = GYTPOL Validator service:

Services won’t start

Certain services could encounter difficulties when starting after system restarts or updates. Any related errors or issues will be documented in the Application log within the Event Viewer. This log provides valuable information about service startup problems and helps identify any issues that need attention.

 

 

 

You have multiple options to troubleshoot and identify errors in this situation, with the event log being the most convenient method.

Using --console switch

Using Command Prompt with administrative privileges, follow these steps to troubleshoot the issue:

1. Navigate to the folder associated with the service. This information can be found in the "Path to Executable" line in the services section.

2. Locate the executable file related to the service.

3. Run the executable by typing its name followed by "--console" and press Enter. For example, if the executable is "Analyzer.exe," you would type "Analyzer.exe --console".

4. This command will display the service startup process and potentially provide more information about any errors encountered during startup.

 

Using --migrate switch

If you encounter situations where certain database migrations are taking longer than anticipated, leading to service startup timeouts, you can address this issue through the following steps:

1. Navigate to the service's folder using Command Prompt with administrative privileges.

2. Locate the relevant executable file (e.g., "Analyzer.exe") related to the service.

3. Run the executable with the "--migrate" parameter. For example, type "Analyzer.exe --migrate" and press Enter.

 

By running the service executable with the "--migrate" parameter, you will initiate the database migration process. This process ensures that any required additional tables, columns, keys, and other objects are created within the database according to the product's requirements. Importantly, this approach will also handle any timeouts that might occur during the migration process, allowing the database updates to complete successfully.

 

DB in read-only mode

In extremely uncommon instances, the database may enter a read-only mode, causing the migration process to fail. To address this situation, follow these steps:

1. Add the "Everyone" group with Full Control permissions to the security settings of the relevant folder. Ensure that these permissions are applied to all child objects within the folder.

2. Run the service executable with the "--migrate" parameter and allow the migration process to complete.

3. Once the migration is successful, remove the "Everyone" group from the folder's security settings.

4. Start the affected service through the System Services utility.

Could not allocate a new page for database ‘gytpol_<DBNAME>’ because of insufficient disk space in filegroup ‘PRIMARY’

LocalDB (including SQL Express) databases have a maximum disk space allocation of 10GB. If your database file exceeds this limit, the service will fail to start. It's advisable to transfer your databases to an external SQL server, whether it's dedicated or shared. Preferably, opt for a dedicated server for better performance.

Keep in mind that after migration, certain data won't transfer, such as created action rules (mutes, remediations, and auto-remediations) and the activity log of actions.

Analyzer/Data Repository services won’t start - System.NullReference

Console output:

Event Viewer output:

If the issue was caused by a null value in the "Option.json" file located within the "data/RsopRepository/config" directory, please modify the contents of the file to the following:

 

If the issue was caused by a null value in the "Option.json" file located within the "data/Analyzer/config" directory, please modify the contents of the file to the following:

Once done, please start the services - Data Repository first and then Analyzer.

Health screen – all clients missed reports in the last 24 hours or more

If you have experienced a situation where all clients have lost connectivity to the dashboard for the past 24 hours or more, and you see orange or red bars indicating issues, please follow these steps to resolve the issue:

1. Restart the "gytpol Data Repository" service.

2. Restart the "gytpol Analyzer" service as a dependency of the "gytpol Data Repository" service.

After restarting these services, the clients should start reporting their data shortly. This action should help restore connectivity and resolve any issues causing the lack of data reporting to the dashboard.

 

Client – post-installation issues

Client Log location

To gain insight into the causes of any client-related issues, it's recommended to examine the logs found in the directory "C:\Program Files\WindowsPowerShell\Modules\gytpol\Log." By reviewing these logs, you can better investigate and comprehend the specific problems you're encountering.

In this section, we'll delve into a few of the typical problems associated with the GYTPOL client. However, there might be instances where logs alone are insufficient, and you may need to access the archive folder for more comprehensive information. For further details on this, please refer to the provided resource here.