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

Open

• 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:

Open

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.

Remediation / Revert tasks can’t be executed via the UI

Please be aware that remediations and reverts are exclusively accessible using Powershell version 5.1 and later. If your machines are running on older versions of Powershell, they can still undergo scanning and provide reports, but the remediation and revert features will not be available.

Please refer to the client installation document for more details: Client Installation - GYTPOL

Client is not reporting to GYTPOL – Windows

Communication issues

The primary issue that arises frequently is blocked communication. In situations where port 9093 is obstructed, the client's capacity to establish communication with the central server becomes compromised, subsequently resulting in the failure of report transmission.

To determine whether this issue is at play, you can conduct a connection test using PowerShell:
Test-NetConnection _gytpol -port 9093

It's important to note that this test encompasses both connectivity and DNS resolution. It's crucial that the hostname "_gytpol" resolves to the same server name as the Fully Qualified Domain Name (FQDN) of the GYTPOL application server.

Should the test yield a "False" result, it's recommended to collaborate with your network team to inspect and potentially open the requisite ports to rectify the issue.

NullReferenceException in client logs

If the client isn’t reporting and the log shows this:

Please verify that all the files in C:\Program Files\WindowsPowerShell\Modules\gytpol\Config are present.

There should be four files in total, as listed below.

Please also ensure that "state.json" is not empty and that "client.json" contains the following information:

If the "state.json" file is empty or contains NULL values, please delete the file and run the gytpolTask to initiate a scan. The scan should recreate the "state.json" file, and the device should report correctly.

Wrong public key

When the public key is not properly generated or undergoes changes (such as server replacement or database migration), it can lead to communication breakdowns. If such issues occur, you might encounter an error in the logs that resembles the following example:

To resolve this issue, you should remove the "gytpol.public" file located in the directory "C:\Program Files\WindowsPowerShell\Modules\gytpol". After deleting this file, run the "gytpolTask" to initiate the scan and check-in process again. This action will help refresh communication and address any problems related to the public key.

FIPS

In certain cases, organizations implement FIPS (Federal Information Processing Standards) hardening on their servers and endpoints to meet regulatory and security requirements. However, this can sometimes lead to communication issues between the GYTPOL client and server, causing the client not to report back and appear in the dashboard. This issue may be indicated in the logs as demonstrated in the provided example. To address this, it's recommended to work with your IT team to carefully manage FIPS settings and ensure compatibility with GYTPOL communication requirements.

To resolve this issue, you can disable FIPS (Federal Information Processing Standards) via Group Policy or Local Policy on the affected server or endpoint. FIPS compliance can sometimes interfere with certain software, including GYTPOL, leading to communication problems.

Tasks not created

The GYTPOL client operates using scheduled tasks rather than running as a 24/7 agent. These tasks are responsible for executing various flows, scans, and remediation processes. During the client installation process, these tasks are automatically created in the "gytpol" folder within the main Task Scheduler Library.

If you're unable to view the tasks in the "gytpol" folder within the Task Scheduler Library, you can try the following steps:

1. Run Task Scheduler as Administrator and look for the tasks in gytpol folder.

2. Install Client as Administrator:

• Open Command Prompt as Administrator by right-clicking on Command Prompt and selecting "Run as administrator."

• Navigate to the directory where the GYTPOL client MSI installer is located.

Error 429 – too much connections

In exceptional situations, the GYTPOL client might encounter difficulties sending reports to the server if numerous clients are reporting simultaneously and the server has a limit on the number of incoming reports it can handle. This limitation can be observed in the "ThrottledURLs" section of the configuration.

In such cases, you might encounter an error in the logs that appears similar to the following:

To increase the number of the parallel connections, please increase the value of "throttledUrls" by increments of 10.

For example, if the current value is 50, you could try increasing it to 60, then 70, and so on, until you are not getting the error anymore (or less frequent).

Remediations and reports are delayed

As mentioned above, “too much connections” can cause the websrv not to get reports due to a long queue of clients sending data at once. To control it, and manage the number of reports, please add the below lines (1 new) to "C:\gytpol\data\WebSrv\websrv_config.json" and restart gytpol WEB UI service:

"throttledUrls": {

    "/upload/rsop/endpoint_report": 20,

    "/upload/analyzer/host/get_task_list": 20

  },

Netskope, browsing isolation, SSL inspection

If Netskope is in use, it has the potential to impact both report generation and encryption integrity. This could result in devices not being visible within the console. It is essential to ensure that client communication with the GYTPOL server does not pass through any intermediary appliances, proxies, or firewalls that could compromise encryption or alter certificates.

Active Directory tab is empty / not updating

To verify the health status of the Active Directory security and misconfiguration pages, please follow these steps:

Ensure the scheduled tasks on the GYTPOL server are running successfully. Check the following tasks:

• gytpolServer

• gytpoServerDaily

• gytpolServerWeekly

You can review the "History" tab for each of these tasks to confirm their successful execution.

Additionally, you have the option to run these tasks manually. While doing so, please ensure the following:

• The tasks run for a short period of time without immediate failure.

• During the runtime, monitor for the creation and subsequent deletion of files in the C:\gytpol\data\Output folder.

• After the tasks have completed their run, verify the presence of files in the C:\gytpol\data\GpoCache folder.

Next, make sure that the user configured to run the tasks has proper permissions according to the installation guide https://gytpol.com/resource/system-requirements/

Once the tasks complete its run successfully, please make sure you see misconfigurations in the GYTPOL Dashboard in the ‘Active Directory’, ‘AD/GP Maintenance’, ‘CIS’ and ‘NIST’ panes.

Proxy check

If your device (server or endpoint) is accessing the internet through a proxy server, it can potentially cause issues with GYTPOL client reporting and accessing the GYTPOL application. Here are a few ways to check if the server is reporting via a proxy:

Check System Proxy Settings:

• Open the Control Panel on the device.

• Navigate to "Internet Options" or "Network and Sharing Center."

• Look for proxy settings under the "Connections" tab or "Internet Options."

• If a proxy server is configured, it might affect the GYTPOL client's communication.

Check Command Prompt for Proxy Settings:

• Open a Command Prompt as Administrator.

• Run the following command to view proxy settings:

If a proxy server is configured, it will be displayed in the command output.

Powershell:

If proxy is set, this will be the result:

Google Chrome:

In the proxy settings page, open the manual proxy server setup and look for the address.

Make sure that GYTPOL client can report the application server without going through proxy server.

winhttp

If you have no proxy set, but the logs still show proxy, please run
netsh winhttp show proxy in CMD as Admin.

dsRequester can’t be installed

When encountering error 1603 with the message "running scripts is disabled on this system," follow these steps to resolve the issue:

MSI (s) (10:5C) [09:52:57:625]: Executing op: CustomActionSchedule(Action=ca_registerTasks,ActionType=3073,Source=BinaryData,Target=WixQuietExec64,CustomActionData="PowerShell.exe" -Command "Import-Module 'C:\Program Files\WindowsPowerShell\Modules\gytpolServer\gytpolServer.psm1' -Force; Register-gytTasks" "eyJneXRTZXJ2ZXJVcmlNYXNrIjoiaHR0cHM6Ly92dDYxZXp0NHE2LmV4ZWN1dGUtYXBpLnVzLWVhc3QtMi5hbWF6b25hd3MuY29tL3Byb2QvIiwiZ3l0U2VydmVyQXBpS2V5IjoiWUNVcmFiTTFjWDV4WkR4NE1uR3IzYkRJS1ZyUVA2ODFFMWJsS3R1YSJ9")
MSI (s) (10:5C) [09:52:57:625]: Creating MSIHANDLE (74) of type 790536 for thread 8284
MSI (s) (10:B0) [09:52:57:625]: Invoking remote custom action. DLL: C:\Windows\Installer\MSIE313.tmp, Entrypoint: WixQuietExec64
MSI (s) (10!6C) [09:52:58:460]: Creating MSIHANDLE (75) of type 790531 for thread 8556
WixQuietExec64: Import-Module : File C:\Program Files\WindowsPowerShell\Modules\gytpolServer\gytpolServer.psm1 cannot be loaded
MSI (s) (10!6C) [09:52:58:460]: Closing MSIHANDLE (75) of type 790531 for thread 8556
MSI (s) (10!6C) [09:52:58:475]: Creating MSIHANDLE (76) of type 790531 for thread 8556
WixQuietExec64: because running scripts is disabled on this system. For more information, see about_Execution_Policies at
MSI (s) (10!6C) [09:52:58:475]: Closing MSIHANDLE (76) of type 790531 for thread 8556
MSI (s) (10!6C) [09:52:58:475]: Creating MSIHANDLE (77) of type 790531 for thread 8556
WixQuietExec64: https:/go.microsoft.com/fwlink/?LinkID=135170.

To resolve Error 1603 with "Running Scripts is Disabled on this System"

When encountering error 1603 with the message "running scripts is disabled on this system," follow these steps to resolve the issue:

Step 1: Change the PowerShell Execution Policy

1. Open PowerShell as Administrator:

   • Click on the Start menu.

   • Type powershell.

   • Right-click on Windows PowerShell and select "Run as administrator."

2. Set the Execution Policy:

   • In the PowerShell window (running as administrator), type one of the following commands and press Enter:

     • For RemoteSigned (scripts created locally are allowed, remote scripts need to be signed):

       Copy code

       Set-ExecutionPolicy RemoteSigned

     • For Unrestricted (all scripts are allowed to run for testings):

       Copy code

       Set-ExecutionPolicy Unrestricted

3. Confirm the Change:

   • If prompted, type Y and press Enter to confirm the change.

Step 2: Modify Group Policy Settings

1. Open Group Policy Editor:

   • Press Win + R to open the Run dialog.

   • Type gpedit.msc and press Enter.

2. Navigate to PowerShell Settings:

   • In the Group Policy Editor, navigate to Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell.

3. Ensure Script Execution is Allowed:

   • Locate the "Turn on Script Execution" policy.

   • Ensure it is set to "Not Configured" or "Enabled" with an appropriate execution policy that allows script execution.

Step 3: Additional Troubleshooting (if needed)

1. Disable Antivirus Temporarily:

   • Temporarily disable your antivirus software and try running the installer again.

2. Run Installer as Administrator:

   • Right-click the installer and select "Run as administrator."

3. Clear Temporary Files:

   • Delete temporary files from %temp% and C:\Windows\Temp.

4. Restart Windows Installer Service:

   • Open the Run dialog (Win + R), type services.msc, and press Enter.

   • Locate "Windows Installer," right-click it, and select "Restart."

Client can’t be upgraded

For comprehensive instructions on performing on-premises upgrades for Windows, Linux, and macOS clients, please consult the guide available at https://gytpol.com/resource/client-update-manual/.

Once you've ensured that all configurations are in order, it's important to verify that you can successfully download the MSI file, as outlined in the following section.

Clients can’t pull the MSI update file

If you have configured an update but it's not being deployed, it's important to follow these steps:

1. Check MSI File Access: Verify that the targeted PCs or servers can access the MSI file URL as specified in the clientUpgrade.json configuration. To test this, copy the URL from the JSON file and paste it into a browser on a non-updated PC or server. If the file cannot be downloaded, ensure that the URL is accurate and accessible through the specified port mentioned in the JSON file.

2. Event Viewer for 1603 Errors: If you can successfully download the file but the update is still not being applied, investigate the Event Viewer for events related to msiInstalled. Specifically, look for a 1603 error. This error might indicate that there are antivirus (AV) or endpoint detection and response (EDR) solutions blocking the installation.

3. EDR Exclusions: If you find a 1603 error in the Event Viewer, it's likely due to AV or EDR blocking the update. Check whether your AV or EDR solution has exclusions or rules that might be preventing the MSI file from being installed. Make sure that the paths, URLs, and processes associated with GYTPOL are properly excluded to allow for smooth updates.

MSIEXEC cache (SCCM, BigFix, PDQdeploy etc.)

Occasionally, the MSI installer may fail to run due to missing cached MSI files, often occurring after SCCM deployment. If this issue arises, you may encounter the following error message:

To resolve this error, follow these steps to delete the source folders (cached files location) from the Windows Registry Editor:

1. Open Registry Editor: Press Win + R to open the Run dialog, type regedit, and press Enter. This will open the Windows Registry Editor.

2. Navigate to GYTPOL GUID: In the Registry Editor, navigate to the following location:

1. Delete SourceList Subkeys: Under the SourceList key, you should see subkeys named "Media" and "Net." Right-click on each of these subkeys and select "Delete" to remove them.

2. Confirm Deletion: Confirm the deletion when prompted.

3. Close Registry Editor: After deleting the subkeys, close the Registry Editor.

Once you have deleted the "Media" and "Net" subkeys from the SourceList in the Registry, attempt to reinstall or repair the GYTPOL software using the original MSI installer. This should resolve the issue related to missing cached files and allow the installation or repair process to complete successfully.

If you require a PowerShell script to automate the process of resolving the issue related to missing cached MSI files, you can contact GYTPOL support at support@gytpol.com. They will be able to provide you with the necessary script and guidance to perform the required actions automatically.

Miscellaneous

Advanced troubleshooting – Archive folder

To enable advanced troubleshooting by providing the GYTPOL support team with a complete flow of the scan and remediation actions, you can create an archive folder as follows:

1. Open the file "C:\Program Files\WindowsPowerShell\Modules\gytpol\Config\client.json" using an elevated text editor, like Notepad run as Administrator or Notepad++.

2. Locate the line that specifies "archiveEnabled": false.

3. Change "archiveEnabled": false to "archiveEnabled": true.

4. Save the changes to the file.

5.  

Once you've made this change, a folder named "archive" will be created in the "C:\Program Files\WindowsPowerShell\Modules\gytpol" directory. This folder will contain logs and information that can be shared with the GYTPOL support team for advanced troubleshooting purposes.

Each individual task, scan, or remediation action initiated by GYTPOL will generate a corresponding folder containing logs, commands, and results. These folders are valuable for diagnosing any failures or issues during the process.

After the desired troubleshooting steps have been taken and the flow is complete, you can follow these steps:

1. Locate the folder related to the specific task, scan, or remediation that you wish to troubleshoot. This folder can be found within the "archive" folder created in the "C:\Program Files\WindowsPowerShell\Modules\gytpol" directory.

2. Zip the entire folder to create a compressed file.

3. Email the zipped folder to the GYTPOL support team at the provided email address.

The GYTPOL support team will then be able to analyze the logs and information within the zipped folder to assist in identifying and resolving any issues.

To revert the change made to the "archiveEnabled" field and disable the creation of the archive folder, you can follow these steps:

1. Open the client.json file where the "archiveEnabled" field is located. This file is likely located in the "C:\Program Files\WindowsPowerShell\Modules\gytpol" directory.

2. Locate the "archiveEnabled" field in the configuration file.

3. Change the value of the "archiveEnabled" field from "true" to "false".

4. Save the changes to the configuration file.

By setting the "archiveEnabled" field to "false," GYTPOL will no longer create the "archive" folder and store logs and data for each task, scan, or remediation action.

Servers Allowed RE

To enable the Cloud API reporting feature for Windows Server OS in GYTPOL, you can follow these steps:

1. Navigate to the "C:\Program Files\WindowsPowerShell\Modules\gytpol\Config" directory on your server.

2. Locate the "predefined.json" file within the directory.

3. Open the "predefined.json" file using an elevated text editor, like Notepad run as Administrator or Notepad++.

4. In the "predefined.json" file, find the entry labeled "serversAllowedRE."

5. Change the value associated with "serversAllowedRE" from "false" to "true."

6. Save the changes to the "predefined.json" file.

By setting the "serversAllowedRE" value to "true," you're allowing Windows Server OS to report via the Cloud API (Remote Employees feature) in GYTPOL. This feature is useful when internal communication is blocked or the FQDN cannot be resolved for reporting purposes.

After making the change to allow Cloud API reporting for Windows Server OS in GYTPOL by setting "serversAllowedRE" to "true" in the "predefined.json" file, the GYTPOL client on Windows Server OS will attempt to report via the Cloud API if it cannot reach the GYTPOL server through the internal 9093 port. This provides an alternative reporting method for situations where direct communication to the server is not possible.

Filtering AWS IP Addresses for Specific Services Using jq and curl

AWS publishes their IP addresses in a JSON file, which can be downloaded and filtered using the jq command. The following command displays the IP ranges for the services we use, assuming curl and jq are installed:

curl https://ip-ranges.amazonaws.com/ip-ranges.json | jq '.prefixes[] | select(((.region == "us-east-2") and (.service == "S3")) or ((.region == "us-east-2") and (.service == "API_GATEWAY")) or ((.region == "us-east-2") and (.service == "AMAZON")) or ((.region == "us-east-2") and (.service == "EC2"))) '

JQ

For Windows:

1. Download jq:

   • Visit https://stedolan.github.io/jq/download/

2. Download the 64-bit or 32-bit Windows binary (jq-win64.exe or jq-win32.exe).

3. Place jq in PATH:

   • Extract the downloaded ZIP file.

   • Move jq.exe to a directory in your system's PATH (e.g., C:\Windows\System32).

4. Verify Installation:

   • Open Command Prompt and type jq --version to ensure it's installed correctly.

For macOS:

1. Using Homebrew:

   • Open Terminal.

   • Run brew install jq to install jq.

2. Verify Installation:

   • In Terminal, type jq --version to verify the installation.

For Linux (Ubuntu/Debian):

1. Using Package Manager:

   • Open Terminal.

   • Run sudo apt-get update && sudo apt-get install jq to install jq.

2. Verify Installation:

   • In Terminal, type jq --version to verify the installation.

CURL

For Windows:

1. Download curl:

   • Visit https://curl.se/windows/

2. Download the latest curl executable for Windows, either 32-bit or 64-bit.

3. Install curl:

   • Run the downloaded executable and follow the installation prompts.

4. Verify Installation:

   • Open Command Prompt and type curl --version to ensure it's installed correctly.

For macOS:

1. Already Installed:

   • curl is usually pre-installed on macOS.

2. Verify Installation:

   • Open Terminal and type curl --version to verify the installation.

For Linux (Ubuntu/Debian):

1. Using Package Manager:

   • Open Terminal.

   • Run sudo apt-get update && sudo apt-get install curl to install curl.

2. Verify Installation:

   • In Terminal, type curl --version to verify the installation.

Common issues

UI is stuck / not refreshing

If you encounter issues where the GYTPOL UI is not refreshing, becomes unresponsive, or experiences frequent timeouts while navigating between screens, a potential solution is to restart the "gytpol Data Repository" service. Additionally, remember to restart the "gytpol Analyzer" service as a dependency for a comprehensive solution. This can help resolve any performance-related issues and restore the responsiveness of the GYTPOL UI.

Clients stop reporting

To diagnose network connectivity issues with non-reporting clients/devices or the subnet they are located in, you can perform the following steps:

1. Open PowerShell on the non-reporting client/device.

2. Run the following command: Test-NetConnection _gytpol -port 9093

• If TcpTestSucceeded is true, it indicates that the connection test was successful. In this case, you should provide the relevant logs to the GYTPOL support team for further assistance. The log's location can be found according to the instructions provided by GYTPOL support.

• If TcpTestSucceeded is false, it suggests that the connection test failed. In this situation, you need to communicate with your networking team to ensure that TCP port 9093 is allowed between the non-reporting client/device and the GYTPOL server. Resolving the network connectivity issue should allow the clients to communicate with the GYTPOL server successfully.

Remediations aren’t working after DB migration to external SQL server

When transitioning the GYTPOL database from a localDB to an external SQL server, a situation may arise where the task keys are reset. For instance, if the last recorded task key in the localDB was #15, moving to the new external database could lead to the starting task key being set to #1. This shift in task key sequence can pose a challenge when the GYTPOL client expects the next task to have a key higher than the last one it processed. For example, the client might expect task #16 after completing task #15 but instead encounters task #1.

To address this issue, follow these steps:

1. Open SQL Server Management Studio: Launch SQL Server Management Studio and connect to the database where GYTPOL's Analyzer data is stored.

2. Execute Query: Open a new query window and make sure you're connected to the Analyzer database. Then, run the following SQL query:

ALTER SEQUENCE RemediationTaskIds RESTART WITH 1000;

Execute Query: After entering the query, execute it by clicking the "Execute" button or pressing the F5 key.

By running this SQL query, you're restarting the sequence for the RemediationTaskIds column in the Analyzer database. This helps ensure that the task keys maintain their expected sequence and prevent any disruption in task processing caused by changes in the task key numbering.

Error messages (services, timeouts)

Before proceeding with troubleshooting, ensure that you are using the latest versions of Chrome or Edge browsers, as GYTPOL does not support browsers below version 100. To gain insights into the behavior of the screens and the functions being loaded, follow these steps:

1. Open the web page where you are encountering the issue in Chrome or Edge.

2. Press the F12 key to open the developer tools.

3. In the developer tools panel, navigate to the "Network" tab.

4. Reproduce the action that leads to the error or issue.

5. When the error message appears, you will see requests and responses being recorded in the "Network" tab.

6. Locate the error message entry and click on it to view details.

7. Open the "Payload" tab to see the data being sent and received during the request.

8. Capture a screenshot or gather relevant information from the "Network" tab, "Payload" tab, and any other relevant tabs that show the waterfall of loading screens, functions, payload, and responses.

9. Provide this collected information to the GYTPOL support team for further analysis. This data will help them understand the issue and provide appropriate guidance or solutions.

By providing the detailed information from the developer tools, the GYTPOL support team will be better equipped to diagnose and address the issue you are encountering with the GYTPOL web application.

Error 500 on Analyzer - VDI file

If you have made changes to the VDI Images file as described in the provided instructions, ensure that you have edited the vdiImages.json file correctly and maintained the proper JSON format. Incorrect editing of this JSON file can lead to errors in the Analyzer service, which will be reflected in the Event Viewer.

If you encounter errors related to the .Net Runtime in the Event Viewer, pay attention to the error message. If you see references to the GetVdiConfig function, it indicates that there might be issues with the vdiImages.json file. The JSON file might not have been edited properly or the JSON format may not have been maintained.

To resolve this issue:

1. Check the vdiImages.json file to ensure that it follows the correct JSON format and structure. Any syntax errors or inconsistencies could prevent the Analyzer service from starting.

2. If you're unsure about the validity of the JSON in the file, you can use online JSON validators to verify its correctness.

3. Once you've corrected any errors in the JSON file, save it and restart the Analyzer service.

By ensuring that the vdiImages.json file is edited correctly and maintains the proper JSON format, you can prevent errors and ensure the smooth functioning of the GYTPOL Analyzer service.

SQL server and Analyzer service

When transitioning to a dedicated SQL Server, it's necessary to define and redirect connection strings in various configuration files, such as analyzer.json. These changes ensure that the GYTPOL Analyzer service can communicate with the new SQL Server. If you encounter issues where the GYTPOL Analyzer service fails to start after making these changes, there's a specific configuration flag you need to check in the appsettings.json file.

Please ensure that the Encrypt=False flag is present in the appsettings.json file. This flag is crucial when using a dedicated SQL Server. The absence of this flag or an incorrect value can lead to connectivity issues between the GYTPOL Analyzer service and the SQL Server.

By confirming the presence of the Encrypt=False flag in the appsettings.json file, you can help ensure that the GYTPOL Analyzer service can establish a secure connection to the dedicated SQL Server, allowing the service to function properly.

Services won’t start

If you're facing difficulties in starting the gytpol GPMC Proxy service or any other service that is supposed to run under a user account (instead of the SYSTEM account), there are a couple of important factors to consider:

1. User Credentials: Ensure that you have correctly entered the username and password for the user account that the service is supposed to run under. Mistyped or incorrect credentials will prevent the service from starting.

2. Logon as a Service Privilege: To run a service under a specific user account, that user account needs to have the "Logon as a Service" privilege. If this privilege is not granted, the service will not be able to start. You can check and grant this privilege by following these steps:

• Open the Local Security Policy editor (secpol.msc) on the server.

• Navigate to "Local Policies" > "User Rights Assignment."

• Look for the "Log on as a service" policy.

• Add the user account you're using for the service to this policy. If the account is not listed, you can add it.

User Group Membership: The user account should be a member of the appropriate groups required for the service to function correctly. These groups might include "Administrators" or other custom groups necessary for GYTPOL services.

By verifying and ensuring these factors, you can troubleshoot issues related to starting services under specific user accounts. Proper user credentials, privileges, and group memberships are essential for services to run smoothly and reliably.

Tasks won’t be created – GYTPOL server

When the application server is installed, please make sure that the gytpolServer tasks (3 total) are created.

If you can’t see the tasks under the main Task Library, please make sure that storage of Network Credentials is allowed on the server and re-run the installation.

Server RAM leak

If you observe elevated RAM usage by the DLLHOST.exe process, you can address this issue by making the following change to the gytpolServer task. Please note that if the task is currently running, you should follow the given rule:

1. Stop the Existing Instance of gytpolServer: If the gytpolServer task is already running, you should stop the existing instance before making the change.

2. Modify gytpolServer Task Settings: Open the Task Scheduler and navigate to the gytpol folder in the main Task Scheduler Library. Locate the gytpolServer task and change the task behaviour as shown in the picture below:

Policy Validation – error 299 / empty screens / GPMC service is down

System alerts can be accessed by clicking on the triangle icon located in the top right corner of the screen:

You will also see error in the Policy Validation screen, in a red notification icon:

In case you see error 201, please make sure that gytpol GPMCProxy service is running.

In case you see error 299, please follow the below steps:

DCs empty

As explained in the GPMCProxy section, the "dcs.json" file is populated during the server installation. If the "dcs.json" file is empty, the GPMCProxy module won't be able to perform modeling as it can't locate the list of domain controllers (DCs).

To address this issue, ensure that the "dcs.json" file contains the necessary data. Also, verify that the domain controllers listed in the file are accessible through the required ports mentioned in the System Requirements document. Additionally, make sure that the domain controllers are within the same Active Directory site as the GYTPOL server.

Modeling wizard not working: updates / permissions

If your list of domain controllers (DCs) is correct, but you're still experiencing issues where the Policy screens are empty, you can try running a Group Policy Modeling Wizard via the Group Policy Management console using GYTPOL account credentials. This may help diagnose and troubleshoot the problem. Here's how:

1. Open the Group Policy Management console on your Windows server.

2. Navigate to the "Group Policy Modeling" section.

3. Right-click on "Group Policy Modeling" and select "Group Policy Modeling Wizard."

Follow the wizard's steps to simulate a group policy modeling analysis for any user or computer that's experiencing the issue. This process will help you identify any potential issues with the application of group policies and why the Policy screens in GYTPOL might be empty.

If you are able to successfully start the modeling wizard and proceed through all the screens to generate a modeling report, ensure that you follow these steps:

1. Access Denied Issue: If you encounter an "Access Denied" error during the modeling wizard, verify that the necessary Group Policy Object (GPO) delegations are configured as specified in the System Requirements documentation. Make sure that the account you are using to run the modeling wizard has the required permissions to access and analyze the GPO settings.

2. Update Server and Services: If GPO delegations are correctly set up and you still face issues, it's recommended to update the server by running Microsoft Updates until it's fully updated. After updating, restart the "gytpol GPMCproxy" and "gytpol Validator" services. Allow the system to sync for up to an hour.

3. Check Screens After Sync: Once the sync has completed, check the status of the screens in the GYTPOL interface. Make sure that the Policy screens are populated with the relevant information. If the screens are still empty or not showing the expected data, consider the following additional steps:

• Verify that the GPOs and AD data are being properly collected by GYTPOL.

• Check the logs and event viewer for any relevant errors or warnings that could provide insights into the issue.

• Contact GYTPOL support for further assistance if the problem persists.

Misc.

EDR exclusions

To ensure that GYTPOL operates smoothly without interference from antivirus/endpoint detection and response (AV/EDR) scans, it's essential to exclude specific paths from scanning. Excluding these paths can prevent issues with scans, reports, and false positive alerts in SIEM systems. Here are the recommended paths to exclude from scans for both the GYTPOL server and GYTPOL client:

For GYTPOL Server: Exclude the following path from AV/EDR scans:

C:\gytpol\*

For GYTPOL Client: Exclude the following paths from AV/EDR scans:

• C:\windows\installer\*\gytpolClient.exe

• C:\windows\temp\gytpol*

• C:\Program Files\WindowsPowerShell\Modules\gytpol\*

• C:\Windows\System32\WindowsPowerShell\Modules\gytpol\* (Windows 7 and Server 2008 only)

Excluding these paths from AV/EDR scans will help prevent any disruptions to GYTPOL's functionality and ensure accurate reporting and analysis. It's important to keep these exclusions in place to maintain the proper operation of GYTPOL and avoid unnecessary alerts or errors.

GYTPOL certificate whitelisting

In some cases, whitelisting the specified paths isn't sufficient, and you need to add a vendor's certificate to the EDR. To obtain the certificate file, open the Certificates snap-in in MMC, navigate to Local Machine, and locate the GYTPOL LTD certificate in Trusted Publishers.

Ensure this certificate is whitelisted in your EDR, as well as any executable or process that runs with it.

Here's how to open the Certificates snap-in using the Microsoft Management Console (MMC):

1. Open the Run dialog:

   • Press Windows key + R on your keyboard.

2. Launch MMC:

   • In the Run dialog box, type mmc and press Enter.

3. Add the Certificates snap-in:

   • In the MMC window, click on File in the top-left corner, and then select Add/Remove Snap-in.

4. Select the Certificates snap-in:

   • In the Add or Remove Snap-ins dialog box, find and select Certificates from the list on the left, then click Add.

5. Choose the appropriate account:

   • You will be prompted to choose the snap-in to manage certificates for:

     • Select Computer account and click Next.

     • Choose Local computer (the computer this console is running on), then click Finish.

6. Locate the GYTPOL LTD certificate:

   • Back in the MMC console, expand Certificates (Local Computer) in the left pane.

   • Expand Trusted Publishers and then click on Certificates.

   • Locate the GYTPOL LTD certificate in the right pane.

7. Whitelisting the certificate:

   • Ensure to whitelist this certificate in your EDR, as well as any executable or process that runs with it.

This will allow you to view and manage certificates on your local machine using MMC.

Cybereason version with GYTPOL whitelisting:

Starting from Cybereason versions 22.1 (.180 and above) and 21.2 (.480 and above), GYTPOL is already whitelisted. This means that GYTPOL has been added to the list of trusted applications by Cybereason's Endpoint Detection and Response (EDR) solution. As a result, there should not be any blocks or disruptions caused by Cybereason EDR for GYTPOL operations.

If you encounter any issues related to GYTPOL functionality or communication due to Cybereason EDR, please ensure that your Cybereason version is in line with the specified versions (22.1 .180 and above, or 21.2 .480 and above). Keeping your Cybereason version up-to-date can help ensure that GYTPOL whitelisting remains effective and that there are no conflicts between the two security solutions.

Executable files used by client

Here is a list of the executable files used by the GYTPOL client, along with their corresponding paths:

GYTPOL Client Executables:

• C:\Program Files\WindowsPowerShell\Modules\gytpol\Client\fw4_6_2\GytpolClientFW4_6_2.exe

• C:\Program Files\WindowsPowerShell\Modules\gytpol\Client\fw2\GytpolClientFW2.exe

• C:\Program Files\WindowsPowerShell\Modules\gytpol\Client\fw4\GytpolClientFW4.exe

List of Executables Used by the GYTPOL Client During Scans:

• C:\Windows\System32\explorer.exe

• C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

• c:\program files\windowspowershell\v1.0\gytpol\client\gytPSWrapper2.exe

• c:\program files\windowspowershell\v1.0\gytpol\client\gytPSWrapper4.exe

• C:\Windows\System32\rundll32.exe

• C:\Windows\System32\schtasks.exe

• C:\Windows\System32\openfiles.exe

• C:\Windows\System32\dism.exe

• C:\Windows\System32\cmdkey.exe

• C:\Windows\System32\gpresult.exe

• C:\Windows\System32\Dism.exe

• C:\Windows\System32\SecEdit.exe

• C:\Windows\System32\cmd.exe

• C:\Program Files\Mozilla Firefox\uninstall\helper.exe

• C:\Program Files (x86)\Google\Update\ChromeInstaller.exe

• C:\Windows\System32\klist.exe

• C:\Windows\System32\wevtutil.exe

• C:\Windows\System32\inetsrv\appcmd.exe

• C:\Program Files (x86)\Google\Update\GoogleUpdate.exe

• C:\Windows\System32\netsh.exe

• C:\Windows\System32\manage-bde.exe

• C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe

• <$javaPath>\bin\java.exe (replace "<$javaPath>" with the actual path to the Java executable)

• C:\Windows\System32\msiexec.exe

• C:\Windows\System32\net.exe

• C:\Program Files (x86)\VMware\VMware Workstation\VMrun.exe

• C:\Program Files (x86)\Oracle\VirtualBox\vboxmanage.exe

• C:\Windows\SoftwareDistribution\EventCacheManager.exe

These executable files are used by the GYTPOL client to perform various tasks and scans on the system. It's important to have proper exclusions and whitelisting in place to ensure that the GYTPOL client can function without any disruptions caused by security software or policies.

Nutanix and Port 5000 change

If you are using a Nutanix hypervisor and the default port 5000 is already in use, you can follow these steps to change the port for Policy Validation:

1. Log in to the server using the GYTPOLSVC account.

2. Open the "C:\gytpol\data\RsopRepository\Config\urls.json" file in a text editor.

3. Look for the "gpmcProxyBaseUrl" configuration setting. This setting specifies the base URL for the GPMC Proxy service.

4. Change the port value to a port number that is not already in use. For example, you can change it to port 5050.

5. Save the changes to the "urls.json" file.

Open the Advanced System Settings:

• Right-click on "This PC" or "My Computer" (depending on your Windows version) on the desktop or in the File Explorer.

• Select "Properties."

1. In the System Properties window, click on the "Advanced" tab.

2. Under the "Advanced" tab, click the "Environment Variables..." button.

3. In the Environment Variables window for the user, click the "New..." button under the "User variables" section.

4. Enter the following details:

• Variable name: ASPNETCORE_URLS

• Variable value: http://localhost:5050

1. Click the "OK" button to save the new environment variable.

2. Close the Environment Variables and System Properties windows.

3. To apply the changes, restart the "gytpol GPMCPROXY" and "gytpol Data Repository" services:

• Open the Services application:

  • Press Win + R, type services.msc, and press Enter.

• Find and select the "gytpol GPMCPROXY" service, right-click on it, and choose "Restart."

• Find and select the "gytpol Data Repository" service, right-click on it, and choose "Restart."

Rescan of Linux and MacOS clients via terminal

linux:

Open terminal and run

macOS:

Open terminal and run