# Discovery tool The AWS Transform discovery tool helps you automatically discover server inventory in your organization to prepare for migration. The tool supports VMware vCenter, Microsoft Hyper-V, and bare metal (physical) servers. To use the discovery tool, you configure one or more discovery sources, let the tool run, and then review the results in the **Discovered inventory** pane. After you configure a discovery source, the discovery tool begins collecting information. The time that the discovery tool needs to completely analyze your network depends on the size of your environment. For a directional migration business case, you can use the Migration Portfolio Assessment (MPA) files that the tool generates after server collection completes. ## Discovery tool workflow The discovery tool workflow consists of two types of activities: + Configuration activities + Data review and use The following steps describe how to install and use the discovery tool and work with the collected data: 1. Install the discovery tool. 1. Configure discovery sources. You can configure one or more of the following: VMware vCenter, Microsoft Hyper-V hosts, or bare metal servers through a CSV file import. Data discovery begins after you configure any source. 1. Set up OS access and then review the collection status of servers, databases, and network connections. 1. Adjust OS credentials as needed. 1. To generate a migration business case, upload the ZIP file to [Migration assessment](https://docs.aws.amazon.com/transform/latest/userguide/transform-app-assessments.html), or unzip it and upload MPA files from the *mpa\$1exports* directory. The export includes data from all configured sources and contains MPA files for VMware, Hyper-V, and bare metal servers. The discovery tool supports the following discovery paths: + **VMware vCenter auto-discovery** – Automatically discover servers managed by VMware vCenter. + **Hyper-V auto-discovery** – Automatically discover servers managed by Microsoft Hyper-V hosts. + **Bare metal import** – Manually import server inventory through a CSV file. # Setting up the discovery tool ## Installing the discovery tool ### Prerequisites The following are the prerequisites for using the AWS Transform discovery tool: **General prerequisites** + The tool requires 4 vCPU, 16 GB of RAM, and a 35 GB hard disk. + DHCP must be available in the network for the discovery tool VM. + The tool collects data by using a centralized approach. Servers in scope must allow inbound connectivity from the discovery tool VM (default ports, custom port configuration is supported): + Linux – SSH TCP/22 + Windows – TCP/5985 for HTTP, TCP/5986 for HTTPS + SNMP – UDP/161 (used for network collection only, not OS metrics) + For Linux, user accounts that can use SSH to connect to the server. The discovery tool runs various commands over SSH for network collection and OS metrics. Some commands require sudo access: `ss` or `netstat` (network collection), `dmidecode` (server provisioning), and `lvdisplay` (storage provisioning). Each of these commands has a graceful fallback if sudo is not available, but without sudo the discovery tool might not collect all available data. We recommend configuring passwordless sudo for the SSH user to ensure complete data collection. **VMware prerequisites** + VMware vCenter Server version 6.5, 6.7, 7.0, or 8.0. + Permissions to deploy an OVA into your VMware vCenter. + For VMware vCenter Server setup, vCenter credentials with Read and View permissions set for the System group. **Hyper-V prerequisites** + Windows Server with the Hyper-V role enabled. + WinRM enabled on Hyper-V hosts. + A user account with Hyper-V management permissions. + Supported authentication: NTLM (HTTPS only) and Kerberos (HTTP or HTTPS). **Bare metal prerequisites** + A CSV file with server hostnames or IP addresses and the credential names (optional) that map to the friendly names of the OS credentials configured or to be configured on the discovery tool. The CSV must use the following headers: ``` hostname_or_ip,credential_name ``` + Servers must be reachable from the discovery tool VM on the appropriate ports (SSH port 22 for Linux, WinRM port 5985/5986 for Windows). ### Download the discovery tool **VMware installation** 1. Sign in to vCenter as a VMware administrator and switch to the directory where you want to download the discovery tool OVA file. 1. Download the OVA file from this URL: https://s3.us-east-1.amazonaws.com/atx.discovery.collector.bundle/releases/latest/AWS-Transform-discovery-tool.ova **Hyper-V installation** + Download the VHD file from this URL: https://s3.us-east-1.amazonaws.com/atx.discovery.collector.bundle/releases/latest/AWS-Transform-discovery-tool.vhd ### Deploy the discovery tool #### Deploy on VMware 1. Sign in to vCenter as a VMware administrator. 1. Use one of these ways to install the OVA file: 1. **Use the UI:** Choose **File**, choose **Deploy OVF Template**, select the discovery tool OVA file you downloaded in the previous section, and then complete the wizard. Ensure the proxy settings in the server management dashboard are configured correctly. 1. **Use the command line:** To install the discovery tool OVA file from the command line, download and use the VMware Open Virtualization Format Tool (ovftool). To download ovftool, select a release from the [OVF Tool Documentation](https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere-sdks-tools/8-0/ovf-tool-user-s-guide/using-ovf-tool-commands/command-line-options.html) page. This is an example of using the ovftool command line tool to install the discovery tool OVA file. ``` ovftool --acceptAllEulas --name='discovery tool' --datastore=datastore1 -dm=thin ATX-Transform-discovery-tool.ova 'vi://username:password@vcenterurl/Datacenter/host/esxi/' ``` Descriptions of the replaceable values in the example: + The name is the name that you want to use for your discovery tool VM. + The datastore is the name of the datastore in your vCenter. + The OVA file name is the name of the downloaded discovery tool OVA file. + The username/password are your vCenter credentials. + The vcenterurl is the URL of your vCenter. + The vi path is the path to your VMware ESXi host. 1. Locate the deployed discovery tool in your vCenter. Right-click the VM, and then choose **Power**, **Power On**. 1. After a few minutes, the IP address of the discovery tool displays in vCenter. You use this IP address to connect to the discovery tool. ##### VMware virtual machine specifications + **Operating System** – Amazon Linux 2023 + **RAM** – 16 GB + **CPU** – 4 cores + **Disks** – 35 GB + **VMware requirements** – See [VMware host requirements for running AL2023 on VMware](https://docs.aws.amazon.com/linux/al2023/ug/vmware-supported-configurations.html#vmware-host-requirements) #### Deploy on Hyper-V 1. Copy the VHD file to the Windows Server machine that has the Hyper-V role enabled. 1. Open Hyper-V Manager. 1. Choose **New**, and then choose **Virtual Machine**. 1. Complete the setup wizard. On the **Specify Generation** page, select **Generation 1**. Generation 2 virtual machines do not support the VHD format. On the **Assign Memory** page, allocate at least 16384 MB. On the **Connect Virtual Hard Disk** page, choose **Use an existing virtual hard disk** and select the VHD file that you copied. 1. Start the VM. After a few minutes, check the **Networking** tab of the VM in Hyper-V Manager to find the IP address, or connect to the VM console and run `ip addr`. You use this IP address to connect to the discovery tool. ##### Hyper-V virtual machine specifications + **Operating System** – Amazon Linux 2023 + **RAM** – We recommend allocating at least 16 GB + **CPU** – We recommend allocating at least 4 cores + **Disks** – 35 GB (included in the VHD) + **Hyper-V requirements** – See [Hyper-V host requirements for running AL2023 on Hyper-V](https://docs.aws.amazon.com/linux/al2023/ug/hyperv-supported-configurations.html#hyperv-host-requirements) ### Accessing the discovery tool VM + The discovery tool VM comes by default with a username and password ("discovery", "password"). For strong security, we recommend that you update the password by using `sudo passwd discovery` after logging into the VM through your hypervisor's console (for example, vSphere Client for VMware or Hyper-V Manager for Hyper-V). + SSH access is disabled by default. Users can use preconfigured `enablessh` and `disablessh` aliases to enable/disable SSH access to the discovery tool VM. Users can SSH into the VM via `ssh discovery@` after enabling SSH access. Users are encouraged to keep SSH access disabled most of the times and enable it only while actively required. Password change is enforced when running `enablessh`. + To access the discovery tool data directory at `/home/ec2-user/.local/share/DiscoveryTool`, we recommend switching to `ec2-user` by running `sudo su ec2-user`. ## Configure Kerberos authentication Kerberos authentication is the recommended method for connecting to Windows servers from the discovery tool. The discovery tool VM uses native Amazon Linux 2023 Kerberos libraries to authenticate against your Active Directory domain. The following are key points about Kerberos authentication on the discovery tool VM: + Use the `kinit` command to obtain a Kerberos ticket and `klist` to verify the ticket. + The Kerberos configuration file is located at `/etc/krb5.conf`. + Before you configure the discovery tool, verify that `kinit` succeeds from the CLI on the discovery tool VM. ### Kerberos prerequisites Before you configure Kerberos authentication, verify that you have the following information and network connectivity. 1. Obtain the following information from your Active Directory administrator: + The Kerberos realm name (typically your domain name in uppercase, for example, `EXAMPLE.COM`). + The hostname or IP address of the Key Distribution Center (KDC), which is typically a domain controller (for example, `dc01.example.com`). + A service account with permissions to authenticate against the target Windows servers. 1. Verify that the discovery tool VM has network connectivity to the following: + The KDC on port 88 (TCP and UDP) for Kerberos authentication. + The target Windows servers on WinRM ports (5985 for HTTP, 5986 for HTTPS). ### Configure Kerberos Complete the following steps to configure Kerberos authentication on the discovery tool VM. 1. SSH to the discovery tool VM. ``` ssh discovery@ ``` 1. Edit the Kerberos configuration file at `/etc/krb5.conf`. ``` sudo nano /etc/krb5.conf ``` Add the following configuration, replacing the placeholder values with your environment details. ``` [libdefaults] default_realm = EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = true [realms] EXAMPLE.COM = { kdc = dc01.example.com } [domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM ``` **Important** Kerberos is case-sensitive. The realm name must be in uppercase (for example, `EXAMPLE.COM`, not `example.com`). The domain name in the `[domain_realm]` section must be in lowercase. 1. Verify that you can obtain a Kerberos ticket by running the `kinit` command. ``` kinit username@REALM.COM ``` Enter the password when prompted. If the command completes without errors, authentication succeeded. 1. Verify the ticket by running the `klist` command. ``` klist ``` The expected output is similar to the following. ``` Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: username@REALM.COM Valid starting Expires Service principal 01/01/2025 12:00:00 01/01/2025 22:00:00 krbtgt/REALM.COM@REALM.COM ``` 1. Configure the discovery tool with the same case-sensitive principal that you used with `kinit` (for example, `username@REALM.COM`). An explicit `krb5.conf` configuration might not be required if your environment has DNS SRV records configured for Kerberos service discovery. For more information about Kerberos configuration options, see the [MIT Kerberos krb5.conf documentation](https://web.mit.edu/kerberos/krb5-1.12/doc/admin/conf_files/krb5_conf.html) and the [sample krb5.conf file](https://web.mit.edu/kerberos/krb5-1.12/doc/admin/conf_files/krb5_conf.html#sample-krb5-conf-file). ### Find Kerberos configuration from domain-joined machines If you don't have the Kerberos configuration details, you can retrieve them from a Windows machine that is joined to the domain. Run the following commands from a command prompt on the domain-joined machine. To find the domain name, run the following command. ``` echo %USERDNSDOMAIN% ``` Example output: ``` EXAMPLE.COM ``` To find the domain controller hostname, run the following command. ``` nltest /dsgetdc:EXAMPLE.COM ``` Example output: ``` DC: \\dc01.example.com Address: \\10.0.1.100 Dom Guid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx Dom Name: EXAMPLE.COM Forest Name: example.com Dc Site Name: Default-First-Site-Name Our Site Name: Default-First-Site-Name Flags: 0xe00033fd The command completed successfully ``` Map the output to your `krb5.conf` configuration as follows: + **Realm** – Use the value from `%USERDNSDOMAIN%` in uppercase (for example, `EXAMPLE.COM`). + **KDC** – Use the DC hostname from the `nltest` output (for example, `dc01.example.com`). ## Import a self-signed certificate authority into the discovery tool (Optional) This is required when you use WinRM over HTTPS and target servers using WinRM HTTPS certificates signed by a self-signed Certificate Authority (CA), and you want to enable "Validate server SSL certificate" on the discovery tool. ### Prerequisites 1. Self-signed CA certificate that was used to sign the WinRM HTTPS certificates on target servers 1. Certificate in PEM format (.pem or .crt extension) To import a self-signed certificate authority on the discovery tool VM: 1. Ssh to Discovery tool VM 1. Place the CA certificate(s) that signed your target servers' WinRM certificates into trust store directory `/etc/pki/ca-trust/source/anchors/` on the discovery tool VM. For example: `sudo cp winrm-ca.pem /etc/pki/ca-trust/source/anchors/winrm-ca.pem`. Note: If your target servers use certificates signed by different CAs, copy all relevant CA certificates to this directory. 1. Update the certificate trust store: `sudo update-ca-trust` 1. Reboot the VM 1. (Optional) To verify that certificates have been successfully imported, you can run the following command. `sudo trust list —filter=ca-anchors | grep -A 5 ""` See [Installation and configuration for Windows Remote Management](https://learn.microsoft.com/en-us/windows/win32/winrm/installation-and-configuration-for-windows-remote-management) ## Configure discovery tool access **Setup discovery tool** 1. In a web browser access: `https://ip_address:5000`, where *ip\$1address* is the IP address of the discovery tool from Deploy Discovery Tool. The discovery tool uses a self-signed certificate for HTTPS connection which results in a security warning. Choose **Accept the risk and continue** to continue to the discovery tool console. 1. If you're accessing the discovery tool console for the first time, create a discovery tool login password. Create a password, which you will use for future logins. **Important** Remember this password - there is no password recovery mechanism. **To configure discovery tool to access VCenter** 1. On the **Discovery tool** page, under **Step 1. Configure discovery sources**, choose **Configure sources**. 1. On the **Configure discovery sources** page, provide the **vCenter URL/IP**, the **vCenter username** and **vCenter password** and choose **Save configuration**. The discovery tool begins to collect vCenter information, as described in [Discovered Inventory](https://docs.aws.amazon.com/transform/latest/userguide/discovery-tool-data-collection.html#discovery-tool-inventory). After initial configuration choose **Edit vCenter access** in the **Discovery tool status** frame to change your vCenter access settings. **To configure Hyper-V access** 1. On the **Discovery tool** page, under **Step 1. Configure discovery sources**, choose **Configure sources**. 1. On the **Configure discovery sources** page, provide a **friendly name**, the **host FQDN or IP address**, the **authentication type (NTLM or Kerberos)**, the **WinRM username**, and the **WinRM password**. Choose **Save configuration**. The discovery tool begins to collect Hyper-V information, as described in [Discovered inventory](https://docs.aws.amazon.com/transform/latest/userguide/discovery-tool-data-collection.html#discovery-tool-inventory). Collection begins automatically after you save the credentials. For Hyper-V failover clusters, you can add multiple hosts in the same cluster. The tool automatically deduplicates VMs that appear on more than one host. **To import bare metal servers** 1. Navigate to the **Import servers** page from the Discovery tool homepage. 1. Prepare a CSV file with the following columns: `hostname_or_ip` (required) and `credential_name` (optional). + The `hostname_or_ip` value must be a valid IPv4 address or a fully qualified domain name (FQDN). + The `credential_name` value, if provided, must match the friendly name of an OS credential that you already configured (SSH or WinRM). 1. Upload the CSV file. The tool validates all rows and rejects the file if any row is invalid. After a successful import, the tool automatically begins database, network and OS metrics collection for the imported servers, if OS credentials are configured. If you upload another CSV file, existing records are updated without creating duplicates and new records are merged into the inventory. ## Configure the discovery tool for OS access Configure OS access so that the discovery tool can: + Discover databases to perform database assessment and to assist in VM migration, + Track network connections, including the process associated with the connection, to assist in application dependency mapping and wave planning. **Enable discovery tool OS Access** 1. Navigate to the **Set up OS access** page to provide Windows and Linux credentials. 1. Choose a protocol that you want to add credentials for. 1. Provide the required credentials for the selected protocol. 1. Select **Auto-connect** to enable the discovery tool to try all provided credentials on discovered servers until matching credentials are found for each server. See [Using Auto-Connect Feature With Caution](discover-tool-security.md#auto-connect-caution) for important security recommendations regarding the auto-connect feature. 1. Choose **Set up and connect**. When the OS matching process is completed, you see a message that the data collection is in progress, and an error regarding servers for which a credentials match was not found. ### Supported protocols setup You must set up WinRM, SSH, and SNMP protocols on target servers for the discovery tool to communicate with them. #### Set up WinRM and WMI WinRM is automatically installed with all currently-supported versions of the Windows operating system. To verify or edit WinRM configuration, use the `winrm` command line tool: + Verify installed WinRM listeners: `winrm enumerate winrm/config/listener` + Verify WinRM configurations: `winrm get winrm/config` + Example command to set up WinRM: `winrm quickconfig -transport:https` **Listener Ports** Default HTTP port is 5985; HTTPS is 5986. You can use other ports as needed. The ports must be open between the discovery tool and target servers. **Encryption** The discovery tool uses encrypted WinRM communication. We recommend that WinRM listeners on target servers also use encryption: `winrm set winrm/config/service '@{AllowUnencrypted="false"}'` **NTLM vs Kerberos** WinRM authentication protocols Kerberos and NTLM are supported by the discovery tool. NTLM can be used only with HTTPS and Kerberos can be used with both HTTP or HTTPS. **WMI Requirements** Proper WMI access permissions are needed for remote PowerShell WMI query execution. For network collection, ensure these conditions are met: + Allow network connectivity via ICMP + Allow network connectivity via TCP port 135 \$1 ephemeral TCP port range (49152 - 65535) + Disable UAC + Remote DCOM permissions are set up + Create a dedicated service account with minimal required permissions + WMI namespace permissions are set up for Windows accounts with namespaces: `\\root\\standardcimv2`, `MSFT_NetTCPConnection` class For database (SQL Server) collection, a Windows account (local or domain) belonging to the **Local Administrator Group** is required due to complex WMI objects permission requirements. ### Set up SSH + Port 22 must be open between the discovery tool and target servers. + For SSH network collection to work properly, provide a user configured for passwordless sudo. + Ensure that the following commands are available on target Linux servers (installed by default on most distributions): `ss` or `netstat` for network collection, and `lsblk`, `iostat`, `dmidecode`, `smartctl`, `top`, `ps`, `free`, `ip`, and `df` for OS metrics collection. ### Set up SNMP + Port 161/UDP must be open between the discovery tool and target servers + For SNMP v2: Provide a read-only community string that can access TCP connection OIDs. + For SNMP v3: Provide username/password and auth/privacy details with read-only permission that can access TCP connection OIDs The discovery tool requires access to: + `"1.3.6.1.2.1.6.13.1.1." (tcpConnState)` + `"1.3.6.1.2.1.6.19.1.8." (tcpConnectionProcess)` + `"1.3.6.1.2.1.25.4.2.1.2." (hrSWRunName)` ## Updating the discovery tool The discovery tool does not have an automatic updates feature however you will receive a reminder notification after 30 days of installation to update. It is recommended to keep the application up-to-date to receive the latest features and security patches. **To manually update the tool** 1. Download the latest discovery tool image file (OVA for VMware or VHD for Hyper-V) from the provided link. 1. (Optional) We recommend that you delete the previous discovery tool image file before you deploy the latest one. 1. Follow the steps in the Deploy the discovery tool section to deploy the updated version. ## Revoking access You can revoke access for each discovery source independently. When you revoke access for one source, data from other sources is not affected. + **Revoking vCenter access** – Deletes vCenter credentials and VMware-collected data. Does not delete Hyper-V data, bare metal data, or OS credentials. + **Revoking Hyper-V access** – Deletes Hyper-V credentials and Hyper-V-collected data only. + **Deleting bare metal servers** – Removes imported servers from inventory. Downstream collection data (network, database) that was collected from those servers is retained. # Data collection ## Discovery tool collection schedule After your initial discovery collection, the discovery tool continues to run on this schedule: + VMware discovery – every hour + Hyper-V discovery – every hour The discovery tool also collects OS metrics through the following independent modules, each with its own schedule: + Database discovery – once a day + Network metrics – every 15 seconds, might be less frequent for large environments + Server performance metrics – every 10 minutes + Storage performance metrics – every 10 minutes + Server provisioning data – daily + Storage provisioning data – daily + Network interfaces – daily + Running processes – hourly You can independently start, stop, or trigger each OS metrics module by using **Collect data now**. To manually run a collection, from the **Actions** menu choose: + **Start** – Enables the discovery module. + **Stop** – Disables the discovery module. + **Collect data now** – Starts discovery immediately. Use this option, for example, after you make a change in your network. These actions apply per module. You can control OS metrics modules individually. ### OS data collection attempts When a new server is discovered, the discovery tool attempts each configured credential for each IP address and the hostname. After the discovery tool finds a valid credential, it continues to use that credential unless you add a new credential. After a collection failure, the discovery tool attempts to collect networking data for a server after 3 minutes, 30 minutes, 2 hours, and then 6 hours. After 4 failed attempts, the discovery tool continues to try all configured credentials once every 6 hours. ## Discovered inventory After you configure a discovery source, the **Number of discovered servers** value in the **Discovery tool status** frame begins to increment. The discovery status for the configured source changes to **Enabled** in the **Collection module** frame. The inventory page shows servers from all configured sources: VMware VMs, Hyper-V VMs, and imported bare metal servers. Each server shows its source and collection status per module. Navigate to the **Discovered inventory** page to see the servers that the discovery tool has found. From this page, choose **Download inventory** to download a ZIP file (`discovery_tool_export.zip`) that contains up to 28 days of collected data, including MPA files for all configured sources, performance utilization data, database information, and server-to-server communication information. You can download the ZIP file while the discovery tool continues to work, and obtain partial results. Upload this file to [Migration assessment ](https://docs.aws.amazon.com/transform/latest/userguide/transform-app-assessments.html)to obtain a business case for migration. ### Data points collected The discovery tool gathers comprehensive data across VMware, Hyper-V, OS metrics, database, and network components. The following sections detail the specific data points collected for each component. #### VMware data collection This table describes the VMware virtual machine information collected by the discovery tool: | Name | Type | Category | Sample Value | | --- | --- | --- | --- | | vm\$1name | String | VM Info | "w2k22-snmpd-v2-en-us-mssql-2022-testcase4-1" | | vm\$1id | String | VM Info | "vm-30920" | | vm\$1uuid | String | VM Info | "4201ecf8-cc44-ee7e-01da-34dfb2acf6c0" | | powerstate | String | VM Info | "poweredOn" | | host | String | VM Info | "esxi-70-node1.testlab.local" | | primary\$1ip\$1address | String | VM Info | "192.168.0.52" | | cpus | Integer | VM Info | 2 | | memory | Integer | VM Info | 4096 | | total\$1disk\$1capacity\$1mib | Integer | VM Info | 32768 | | os\$1according\$1to\$1the\$1configuration\$1file | String | VM Info | "Microsoft Windows Server 2016 or later (64-bit)" | | max\$1cpu\$1usage\$1pct\$1dec | Float | VM Performance | 79.33 | | avg\$1cpu\$1usage\$1pct\$1dec | Float | VM Performance | 45.06 | | max\$1ram\$1usage\$1pct\$1dec | Float | VM Performance | 63.99 | | avg\$1ram\$1utl\$1pct\$1dec | Float | VM Performance | 29.27 | #### Hyper-V data collection This table describes the Hyper-V virtual machine information collected by the discovery tool: | Name | Type | Category | Sample Value | | --- | --- | --- | --- | | vm\$1name | String | VM Info | "win2022-hyperv-test-01" | | vm\$1id | String | VM Info | "a1b2c3d4-e5f6-7890-abcd-ef1234567890" | | powerstate | String | VM Info | "Running" | | cpus | Integer | VM Info | 4 | | memory\$1mb | Integer | VM Info | 8192 | | disk\$1paths | String | Disk | "C:\$1\$1VMs\$1\$1disk1.vhdx" | | disk\$1size\$1gb | Float | Disk | 127.0 | | network\$1adapters | String | Network | "00:15:5D:01:02:03" | | ip\$1addresses | String | Network | "10.0.1.50" | | host\$1name | String | Host | "hyperv-host-01.example.com" | | host\$1os\$1version | String | Host | "Windows Server 2022 Datacenter" | | cluster\$1name | String | Host | "FailoverCluster01" | | hypervisor | String | VM Info | "Hyper-V" | #### Bare metal data Bare metal servers are not auto-discovered. They are imported through a CSV file. The discovery tool does not collect hypervisor-level data for bare metal servers. Instead, it collects database, network, and OS metrics data by using the OS credentials associated with each server during import. ## Discovery tool's OS-related data ### OS metrics data collection The discovery tool collects OS-level metrics from servers through SSH (Linux) and WinRM (Windows). Data is collected across six sub-modules and exported into six CSV files. #### Server inventory (server\$1inventory.csv) Combines server provisioning (hardware and OS configuration) with aggregated storage performance. Collected every 24 hours. | Name | Type | Category | Sample Value | | --- | --- | --- | --- | | server\$1id | String | Server Info | "vm-web-server-01" | | server\$1name | String | Server Info | "web-server-01" | | resource\$1type | String | Server Info | "virtual\$1machine" | | power\$1state | String | Server Info | "Running" | | os\$1type | String | Server Info | "Linux" | | os\$1name | String | Server Info | "Amazon Linux" | | os\$1version | String | Server Info | "2023" | | primary\$1hostname | String | Server Info | "web-server-01.example.com" | | primary\$1ip\$1address | String | Server Info | "10.0.2.101" | | netmask | String | Server Info | "255.255.255.0" | | total\$1num\$1network\$1cards | Integer | Server Info | 2 | | total\$1num\$1disks | Integer | Server Info | 1 | | cpu\$1count | Integer | Server Info | 4 | | total\$1memory\$1gb | Float | Server Info | 15.88 | | server\$1uuid | String | Server Info | "4201ecf8-cc44-ee7e-01da-34dfb2acf6c0" | | smbios\$1uuid | String | Server Info | "4201ecf8-cc44-ee7e-01da-34dfb2acf6c0" | | cluster\$1name | String | Server Info | "production-cluster-01" | | hypervisor\$1object\$1id | String | Server Info | "vm-30920" | | hypervisor\$1type | String | Server Info | "VMware" | | hypervisor\$1version | String | Server Info | "8.0.0" | | hypervisor\$1hostname | String | Server Info | "esxi-node1.example.com" | | hypervisor\$1host\$1id | String | Server Info | "host-1234" | | hypervisor\$1id | String | Server Info | "4201ecf8-cc44-ee7e-01da-34dfb2acf6c0" | | disk\$1read\$1iops\$1avg | Float | Storage Performance | 12.5 | | disk\$1read\$1iops\$1peak | Float | Storage Performance | 245.0 | | disk\$1write\$1iops\$1avg | Float | Storage Performance | 8.3 | | disk\$1write\$1iops\$1peak | Float | Storage Performance | 180.0 | | disk\$1total\$1iops\$1avg | Float | Storage Performance | 20.8 | | disk\$1total\$1iops\$1peak | Float | Storage Performance | 425.0 | | disk\$1read\$1throughput\$1avg\$1mbps | Float | Storage Performance | 1.2 | | disk\$1read\$1throughput\$1peak\$1mbps | Float | Storage Performance | 24.5 | | disk\$1write\$1throughput\$1avg\$1mbps | Float | Storage Performance | 0.8 | | disk\$1write\$1throughput\$1peak\$1mbps | Float | Storage Performance | 18.0 | | disk\$1total\$1throughput\$1avg\$1mbps | Float | Storage Performance | 2.0 | | disk\$1total\$1throughput\$1peak\$1mbps | Float | Storage Performance | 42.5 | #### Server performance metrics (server\$1performance\$1metrics.csv) CPU, memory, and network throughput utilization. Sampled every 10 minutes, aggregated over 28 days. | Name | Type | Category | Sample Value | | --- | --- | --- | --- | | server\$1id | String | Server Info | "vm-web-server-01" | | data\$1source | String | Server Info | "OS" | | cpu\$1utilization\$1avg\$1pct | Float | CPU | 45.06 | | cpu\$1utilization\$1peak\$1pct | Float | CPU | 79.33 | | cpu\$1count | Integer | CPU | 4 | | memory\$1total\$1gb | Float | Memory | 15.88 | | memory\$1utilization\$1avg\$1pct | Float | Memory | 29.27 | | memory\$1utilization\$1peak\$1pct | Float | Memory | 63.99 | | network\$1in\$1avg\$1mbps | Float | Network | 0.52 | | network\$1in\$1peak\$1mbps | Float | Network | 12.3 | | network\$1out\$1avg\$1mbps | Float | Network | 0.31 | | network\$1out\$1peak\$1mbps | Float | Network | 8.7 | | network\$1total\$1avg\$1mbps | Float | Network | 0.83 | | network\$1total\$1peak\$1mbps | Float | Network | 21.0 | #### Storage performance (server\$1storage\$1performance.csv) Per-volume disk I/O and space utilization. Sampled every 10 minutes, aggregated over 28 days. | Name | Type | Category | Sample Value | | --- | --- | --- | --- | | server\$1id | String | Server Info | "vm-web-server-01" | | data\$1source | String | Server Info | "OS" | | disk\$1volume\$1id | String | Volume Info | "/dev/nvme0n1p1" | | disk\$1mount\$1point | String | Volume Info | "/" | | file\$1system | String | Volume Info | "xfs" | | disk\$1total\$1gb | Float | Disk Space | 30.0 | | disk\$1used\$1gb | Float | Disk Space | 12.5 | | disk\$1free\$1gb | Float | Disk Space | 17.5 | | disk\$1read\$1iops\$1avg | Float | Disk I/O | 12.5 | | disk\$1read\$1iops\$1peak | Float | Disk I/O | 245.0 | | disk\$1write\$1iops\$1avg | Float | Disk I/O | 8.3 | | disk\$1write\$1iops\$1peak | Float | Disk I/O | 180.0 | | disk\$1total\$1iops\$1avg | Float | Disk I/O | 20.8 | | disk\$1total\$1iops\$1peak | Float | Disk I/O | 425.0 | | disk\$1read\$1throughput\$1avg\$1mbps | Float | Disk Throughput | 1.2 | | disk\$1read\$1throughput\$1peak\$1mbps | Float | Disk Throughput | 24.5 | | disk\$1write\$1throughput\$1avg\$1mbps | Float | Disk Throughput | 0.8 | | disk\$1write\$1throughput\$1peak\$1mbps | Float | Disk Throughput | 18.0 | | disk\$1total\$1throughput\$1avg\$1mbps | Float | Disk Throughput | 2.0 | | disk\$1total\$1throughput\$1peak\$1mbps | Float | Disk Throughput | 42.5 | #### Storage configuration (storage\$1config.csv) Physical disk hardware details. Collected every 24 hours. | Name | Type | Category | Sample Value | | --- | --- | --- | --- | | server\$1id | String | Server Info | "vm-web-server-01" | | disk\$1controller\$1id | String | Disk Info | "/dev/sda" | | vmdk\$1vhd\$1file\$1name | String | Disk Info | "web-server-01.vmdk" | | disk\$1volume\$1type | String | Disk Info | "Virtual" | | disk\$1provisioned\$1gb | Float | Disk Info | 30.0 | | disk\$1device\$1type | String | Disk Info | "SCSI HDD" | | disk\$1interface\$1type | String | Disk Info | "SCSI" | | disk\$1protocol | String | Disk Info | "LSI Logic SAS" | #### Network interfaces (network\$1interfaces.csv) Network adapter configuration. Collected every 24 hours. | Name | Type | Category | Sample Value | | --- | --- | --- | --- | | server\$1id | String | Server Info | "vm-web-server-01" | | interface\$1name | String | Interface Info | "eth0" | | interface\$1index | Integer | Interface Info | 2 | | mac\$1address | String | Interface Info | "0A:1B:2C:3D:4E:5F" | | adapter\$1type | String | Interface Info | "vmxnet3" | | virtual\$1network\$1name | String | Interface Info | "VM Network" | | virtual\$1network\$1id | String | Interface Info | "dvportgroup-1234" | | virtual\$1switch | String | Interface Info | "vSwitch0" | | ipv4\$1address | String | IP Config | "10.0.2.101" | | ipv4\$1subnet\$1mask | String | IP Config | "255.255.255.0" | | ipv4\$1gateway | String | IP Config | "10.0.2.1" | | ipv6\$1address | String | IP Config | "fe80::a1b:2cff:fe3d:4e5f" | | ipv6\$1prefix\$1length | Integer | IP Config | 64 | | ipv6\$1gateway | String | IP Config | "fe80::1" | | dns\$1servers | String | IP Config | "10.0.0.2" | | dhcp\$1enabled | Boolean | IP Config | false | | interface\$1status | String | Interface Info | "Up" | | vlan\$1id | Integer | Interface Info | 100 | | is\$1primary | Boolean | Interface Info | true | #### Running processes (process\$1metrics.csv) Snapshot of running processes. Collected every hour, deduplicated over 28 days. | Name | Type | Category | Sample Value | | --- | --- | --- | --- | | server\$1id | String | Server Info | "vm-web-server-01" | | process\$1name | String | Process Info | "sshd" | | process\$1id | Integer | Process Info | 1234 | | process\$1command\$1line | String | Process Info | "/usr/sbin/sshd -D" | | process\$1user | String | Process Info | "root" | ### Network collection The Network collection module helps you discover dependencies among servers in your on-premises data center. This network data accelerates your migration planning by providing visibility into how applications communicate across servers. This module collects network data for servers from all configured sources, including VMware, Hyper-V, and bare metal. It uses WinRM to collect data from Windows servers and uses SSH, SNMPv2, and SNMPv3 to collect data from Linux servers. #### Network data collection The Network collection module captures TCP IPv4 connections in ESTABLISHED or TIME\$1WAIT state. These data points are collected: + Source IP, port, process ID, and process name + Target IP, port, process ID, and process name + State (ESTABLISHED and TIME\$1WAIT) + Transport protocol (TCP) + IP version (IPv4) + Count (number of times this unique connection was observed) ### Database collection The Database collection module gathers database (SQL Server) information from Windows servers across all configured sources, including VMware, Hyper-V, and bare metal. The module uses the WinRM protocol to remotely connect to each Windows server and run PowerShell queries to get information about all installed SQL Server services (components) on the server by using WMI namespaces, registry, and file properties. A SQL Server component is a specific service or feature instance installed as part of a SQL Server deployment on a Windows server. The discovery tool collects Database Engine, Analysis Services, Reporting Services, and Integration Services. #### Database data collection The Database collection module gathers SQL Server component information. This table describes key database data points collected: | Name | Type | Category | Sample Value | | --- | --- | --- | --- | | Engine Type | String | Component | sql\$1server | | Is Engine Component | Boolean | Component | Y | | Status | String | Service | Running, Stopped, StartPending | | Version | String | Service | 2015.131.5026.0 | | Edition | String | Service | Developer Edition (64-bit) | | SQL Service Name | String | Service | MsDtsServer130, Mssql | | SQL Service Type | String | Service | SQL Server service, Integration Services service | | Instance Name | String | Instance | MSSQLSERVER | | Display Name | String | Service | SQL Server (MSSQLSERVER2017) | | Start Mode | String | Service | Automatic, Manual, Disabled | | Service Account Name | String | Service | NT Service/MsDtsServer130 | | Is Clustered | Boolean | Configuration | N | **Note** Full format includes all service types. MPA format includes only database engine components. Not all fields are available depending on the SQL service type and configuration. # Security considerations ## Securing the discovery tool VM **Discovery tool VM security is crucial** because the discovery tool stores all credentials, logs, and customer data on the discovery tool VM. The discovery tool VM has ssh access disabled by default and can only be accessed from client `vCenter UI -> "Launch Web Console"`. The discovery tool VM comes with a default login password "password" for user "discovery". + We recommend that you update this password immediately after deployment. + We **require** you to update the password if you want to enable ssh using the command `enablessh` after logging in using vCenter `Launch Web Console`. Please note, every time this command is called, you need to reset it. ## Securing Credentials **General best practices for Credential Management** + Store credentials securely + Regularly rotate all credentials + Use password managers or secure vaults + Monitor credential usage + Follow the principle of least privilege and only grant the minimum necessary permissions needed **SNMP v2 Credentials** + Use complex, non-default community strings + Avoid common strings like "public" or "private" + Treat community strings like passwords **SNMP v3 Credentials** + Enable both authentication and privacy + Use strong authentication protocols (SHA preferred over MD5) + Use strong encryption protocols (AES preferred over DES) + Use complex passwords for both auth and privacy + Use unique usernames (avoid common names) **WinRM Credentials** + Avoid disabling WinRM certificate check. + We recommend that you create a dedicated service account with minimal required permissions. + Avoid using domain administrator or local administrator accounts when Database (SQL Server) Collection is not needed. **Hyper-V credentials** + Use dedicated service accounts with minimal Hyper-V management permissions. + Avoid using domain administrator accounts. + Hyper-V credentials support NTLM (HTTPS only) and Kerberos authentication. + The discovery tool stores credentials encrypted at rest by using SQLCipher. ## Using Auto-Connect Feature With Caution The discovery tool uses two mechanisms to assign credentials to servers during *OS-level collection*: auto-connect and manual. OS-level collection includes the Network, Database, and OS metrics modules. These modules connect to individual servers from all sources, including VMware VMs, Hyper-V VMs, and bare metal servers. **Manual**: a server can be manually associated with a specific credential. In this case, the discovery tool will use that credential only, failure or success. The user has to manually monitor collection status for that server and make adjustment. **Auto-connect**: if no credential is manually associated with the server, the discovery tool will use auto-connect mechanism for that server. That means: + at the start of each collection round, the discovery tool will get a list of credentials available for that server (based on OS types) and also configured to be "auto-connectable". + The discovery tool will then test all credentials against the server in a loop. + If a working credential is found, the collection round for the server is successful, the discovery tool remembers it and will try it first next time. + If no working credential is found, the collection round for the server has failed + Network module: the server will use a backoff schedule, starting next collection round in 3 min, 30 min, 2 hours, and 6 hours following each failure (similar to exponential backoff). + Database collection: there is no retry. The discovery tool will make 1 attempt for each server every day. **Impacts/Risks**: Only use auto-connect when you are sure that risks are mitigated in your system: **Risk 1**: With auto-connect configured on multiple wrong credentials, automatically trying them against servers could trigger account lockouts for production environments where lockout policies are configured. For example, a data center can set its VMs to lock down after 3 failed SSH login attempts. In this case, if auto-connect is configured for 3 wrong SSH credentials, legitimate account lockouts would happen. If lockouts happen across multiple systems, critical business processes could be impacted, potentially causing cascading failures in dependent systems. In addition, Security Operations Centers could experience alert storms from mass authentication failure events, creating false positive security incidents that drain resources and may mask real attacks. **Risk 2**: Actor with access to the discovery tool (knows discovery tool password) can brute force OS credentials on all servers, by configuring a large number of test credentials and use auto-connect to find the successful ones. **Mitigations**: Follow these guidelines: + Make sure that the discovery tool password is properly secured and known only to authorized actors + Ensure proper credentials are entered for the environment if lockout policies are in place. We recommend only configure known, working credentials even if account lockout policies are absent to ensure minimal operational load on individual VMs. + "Auto-connect" is an opt-in feature. Do not select it and use manual credential assignment if account lockouts is a concern to the environment. ## Bare Metal CSV Import Security When you import bare metal servers by using a CSV file, consider the following security implications: + The CSV file might contain hostnames or IP addresses of internal servers. Treat it as sensitive data. + The `credential_name` column references preconfigured or to be configured credentials by friendly name. The CSV does not contain secrets. + All-or-nothing validation: if any row in the CSV is invalid, the entire upload is rejected. This prevents partial imports that could create a confusing state. + Imported servers are immediately visible in the inventory and eligible for collection. Ensure that OS credentials are correctly scoped before you import. ## Revoking Access Considerations When you revoke access, deletion is scoped to the specific source: + Revoking vCenter access deletes only vCenter data. It does not affect Hyper-V or bare metal data. + Revoking Hyper-V access deletes only Hyper-V data. It does not affect VMware or bare metal data. + Deleting bare metal servers removes them from inventory, but downstream collection data (network, database, OS metrics) is retained. + To remove all source-specific inventory data, you must revoke or delete each source independently. Downstream collection data (network, database, OS metrics) is retained even after all sources are revoked. # Troubleshooting ## Verifying discovery tool connectivity to vCenter When you experience VMware module configuration errors follow these steps to verify connectivity: **Access the discovery tool VM** + Log-in to the discovery tool VM, open Remote Console in vCenter + Username: discovery + Password: password **Test vCenter Connectivity** 1. Test vCenter API Access: ``` curl -v --insecure -u : https://:443/mob ``` 1. Expected Success Output: ``` [ec2-user@discoverytool ~]$ curl -v --insecure -u : https://vcsa/mob > tmp.txt % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 192.168.2.125:443... * Connected to vcsa (192.168.2.125) port 443 (#0) ... * Connection #0 to host vcsa left intact ``` **Test SSL Certificate** 1. Run this command: ``` openssl s_client -showcerts -servername -connect :443 ``` 1. Expected Success Output: + Should show vSphere certificate details + Verifies SSL/TLS connectivity on port 443 ``` [ec2-user@discoverytool ~]$ openssl s_client -showcerts -servername vcsa -connect vcsa:443 CONNECTED(00000003) depth=0 CN = vcsa.onpremsim.env, C = US verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = vcsa.onpremsim.env, C = US verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/CN=vcsa.onpremsim.env/C=US i:/CN=CA/DC=vsphere/DC=local/C=US/ST=California/O=vcsa.onpremsim.env/OU=VMware Engineering -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- --- Server certificate subject=/CN=vcsa.onpremsim.env/C=US issuer=/CN=CA/DC=vsphere/DC=local/C=US/ST=California/O=vcsa.onpremsim.env/OU=VMware Engineering --- ``` ## WinRM Troubleshooting If you're experiencing connectivity issues with WinRM, follow these steps to test the connection. These steps also apply to Hyper-V connectivity issues, because the discovery tool uses WinRM to communicate with Hyper-V hosts. Test basic WinRM connectivity using ports 5985 (HTTP) and 5986 (HTTPS). We need to make sure that connectivity works on port 5986 (HTTPS) ``` # Check WinRM listener configuration winrm enumerate winrm/config/listener # Note: Replace with the target computer's hostname or IP address. Adjust the username and password as needed. # Test WinRM connection on port 5985 (HTTP) $cred = Get-Credential Test-WSMan -Computer -Authentication Negotiate -Credential $cred -Port 5985 # Test WinRM connection on port 5986 (HTTPS) Test-WSMan -Computer -Authentication Negotiate -Credential $cred -Port 5986 ``` If the above tests fail, try establishing a PowerShell session with certificate validation disabled: ``` $cred = Get-Credential $so = New-PsSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck Enter-PSSession -ComputerName -Credential $cred -Port 5985 -SessionOption $so ``` ## Kerberos troubleshooting If you experience Kerberos authentication failures when collecting data from Windows servers, use the following sections to diagnose and resolve common issues. ### Verify network requirements Before you troubleshoot Kerberos authentication, verify that the discovery tool can reach the required network endpoints. **To verify network requirements for Kerberos** 1. Verify DNS resolution to the domain controller. Run the following command from the discovery tool VM: ``` nslookup dc01.example.com ``` Alternatively, you can use `dig`: ``` dig dc01.example.com ``` If DNS resolution fails, verify that the discovery tool VM is configured to use a DNS server that can resolve your Active Directory domain. Check `/etc/resolv.conf` and confirm that the nameserver entries point to your domain DNS servers. 1. Verify connectivity to the Key Distribution Center (KDC) on port 88. Run the following command: ``` nc -zv dc01.example.com 88 ``` Expected output: ``` Connection to dc01.example.com 88 port [tcp/kerberos] succeeded! ``` If the connection fails, verify that no firewall rules block traffic from the discovery tool VM to the domain controller on port 88. 1. Verify connectivity to the target Windows servers on WinRM ports. Run the following commands: ``` nc -zv 5985 nc -zv 5986 ``` If the connection fails, verify that WinRM is enabled on the target server and that firewall rules allow inbound traffic on ports 5985 and 5986. ### Common Kerberos issues The following are common Kerberos issues and their solutions. **Case sensitivity errors** Symptom: You receive a "Server not found in Kerberos database" error during authentication. This error typically occurs when the Kerberos realm name is not in uppercase. Kerberos realms must be specified in uppercase in your `krb5.conf` file. For example, use `EXAMPLE.COM` instead of `example.com`. **Account lockout prevention** The discovery tool uses a backoff mechanism to prevent account lockouts from repeated failed authentication attempts. If your service account becomes locked out, you can reset the collection process by stopping and then starting the collection module through the discovery tool web UI at `https://:5000`. **kinit fails from CLI** The following table lists common `kinit` errors and their solutions. | Error | Cause | Solution | | --- | --- | --- | | Cannot find KDC for realm | The KDC hostname or IP address is not reachable, or the realm is not configured in krb5.conf. | Verify that the krb5.conf file contains the correct KDC hostname and realm. Confirm DNS resolution and network connectivity to the KDC on port 88. | | Preauthentication failed | The password for the service account is incorrect. | Verify the password and try again. If the account is locked out, unlock it in Active Directory before you retry. | | Client not found in Kerberos database | The principal name does not match any account in Active Directory. | Verify that the principal name matches the account name exactly, including case. Use the format username@REALM with the realm in uppercase. | | Cannot resolve network address for KDC | DNS cannot resolve the KDC hostname. | Verify DNS configuration in /etc/resolv.conf. Confirm that the DNS server can resolve the KDC hostname. Test with nslookup or dig. | **Collection fails despite successful kinit** If `kinit` succeeds but data collection still fails, check the following: 1. Verify that the principal name used for collection matches the case used during `kinit` exactly. 1. Verify that the service account has the required permissions on the target servers. 1. Verify that WinRM is enabled on the target servers. 1. Verify that the hostname used for collection matches the hostname registered in Active Directory. **Kerberos works for some servers but not others** If Kerberos authentication succeeds for some servers but fails for others, investigate the following areas: Compare the WinRM configuration on a working server with a failing server. Run the following command on each server: ``` winrm get winrm/config ``` Test connectivity with Remote Desktop to isolate the issue. The discovery tool uses the format `username@DOMAIN`, while Remote Desktop uses the format `DOMAIN\username`. Verify that the service account is a member of the local Administrators group on the failing server. Run the following command on the target server: ``` net localgroup Administrators ``` WMI requires local administrator privileges to access operating system information. SQL Server collection also requires that the service account has local administrator access on the target server. ### Kerberos configuration checklist Use the following checklist to verify your Kerberos configuration before you start data collection. + The `krb5.conf` file exists on the discovery tool VM. + The realm name is in uppercase in `krb5.conf`. + Running `kinit` with the service account succeeds without errors. + Running `klist` shows a valid, non-expired ticket. + The principal name matches the Active Directory account name exactly. + DNS resolution works for the KDC hostname. + Network connectivity to the KDC on port 88 is confirmed. + Network connectivity to target Windows servers on ports 5985 and 5986 is confirmed. ## SNMP Troubleshooting **Access the discovery tool VM** + Log-in to the discovery tool VM, open Remote Console in vCenter + Username: discovery + Password: password **Install SNMP Tools (if needed)** + `sudo yum install net-snmp-utils -y` **Test SNMP Connection to Linux Servers** 1. `snmptable -v 2c -c .1.3.6.1.2.1.6.13.1` 1. Example: ``` #SNMPv2c: snmptable -v 2c -c public 192.168.1.100 .1.3.6.1.2.1.6.13.1 #SNMPv3 (with authentication): snmptable -v 3 -u -a MD5 -A 192.168.1.100 .1.3.6.1.2.1.6.13.1 #SNMPv3 (with privacy): snmptable -v 3 -u -a MD5 -A -x DES -X 192.168.1.100 .1.3.6.1.2.1.6.13.1 ``` ## Network collection errors ### a terminal is required to read the password **Error:** ``` ss command failed on : sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper sudo: a password is required ``` The ss command is prompting for user password. The configured ssh user must be in the sudoers group and be configured with passwordless sudo for the ss/netstat command. To configure passwordless sudo: 1. Create a new sudoers file: ``` sudo vi -f /etc/sudoers.d/ ``` 1. Add the line: ``` ALL=(ALL) NOPASSWD: /usr/sbin/ss, /usr/bin/netstat ``` 1. After this change, running `sudo ss -tnap` and `sudo netstat -tnap` should execute without prompting for a password ### Network collection ran without sudo If you see the following warning on the **Discovered inventory** page: ``` Network collection ran without sudo. Process-level connection data may be missing. ``` This warning indicates that the SSH user account does not have sudo access on the target server. Without sudo, the discovery tool can still collect network connection data, but it cannot determine which process owns each connection. To collect complete process-level connection data, ensure the SSH user has sudo access on the target server. ## OS metrics collection errors ### Missing server UUID for Linux bare metal servers If the discovery tool is unable to collect the server UUID (showing as empty or missing) for Linux bare metal servers, verify that the SSH credentials configured for those servers have sudo privileges. The tool uses `dmidecode` to read the server UUID. If `dmidecode` is not installed, the tool falls back to reading `/sys/class/dmi/id/product_uuid`, which also requires sudo access. Without sudo, neither method can retrieve the UUID. **Resolution:** Ensure the SSH user account provided to the discovery tool has sudo access on the target Linux servers. ## Access issues in Discovered inventory If you see a message in **Server collection status** such as Missing credentials, or Access denied: 1. Select the server on the table of discovered servers. 1. Choose **Manage access credential** You can choose to: 1. Select alternative credentials from the **Select credentials** dropdown. 1. Select **Use new credentials** and provide new credentials. 1. **Save**. The discovery tool retries the connection after you save your changes. ## Common error messages This table describes common UI messages and their explanations: | Message | Location | Explanation | | --- | --- | --- | | One or more credentials contain unknown UUIDs | OS access page | Race condition when two users edit OS credentials at the same time; try again | | A password has already been created | Create password page | Race condition when two users create passwords at the same time; refresh | | Invalid password | Sign-in page | Incorrect password for logging in; contact admin or reach out | | An on-demand collection is already in progress | Inventory page | Race condition when two users start manual collections at the same time; try again after the current manual collection is finished | | An internal error occurred | Various pages | Retry or send logs | | Export failed | Inventory page | Retry or send logs | | Your session has expired. Please log in again. | Sign-in page | Session has timed out, need to login again | # Release notes This section describes the features, improvements, and bug fixes for the AWS Transform discovery tool, organized by release date. | Date | Version | Release notes | | --- | --- | --- | | April 7, 2026 | 1.0.1074 | **New features** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/transform/latest/userguide/discovery-tool-release-notes.html) | | March 26, 2026 | 1.0.1014 | **Bug fixes and improvements** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/transform/latest/userguide/discovery-tool-release-notes.html) | | December 16, 2025 | 1.0.718 | **New features and improvements** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/transform/latest/userguide/discovery-tool-release-notes.html) | | October 31, 2025 | 1.0.0 | **Initial release** Initial launch of the AWS Transform discovery tool. This release includes: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/transform/latest/userguide/discovery-tool-release-notes.html) |