diff --git a/docs/auto-discovery/cloud-auto-discovery/index.mdx b/docs/auto-discovery/cloud-auto-discovery/index.mdx index c745a9b9..a05964d0 100644 --- a/docs/auto-discovery/cloud-auto-discovery/index.mdx +++ b/docs/auto-discovery/cloud-auto-discovery/index.mdx @@ -16,8 +16,8 @@ Device42 discovers cloud virtual machines, databases, and storage as devices. Th diff --git a/docs/auto-discovery/cloud-auto-discovery/other-cloud-autodiscoveries.mdx b/docs/auto-discovery/cloud-auto-discovery/other-cloud-autodiscoveries.mdx index 4f1c866e..24e22036 100644 --- a/docs/auto-discovery/cloud-auto-discovery/other-cloud-autodiscoveries.mdx +++ b/docs/auto-discovery/cloud-auto-discovery/other-cloud-autodiscoveries.mdx @@ -18,6 +18,7 @@ Device42 discovery supports the following cloud types, as listed in the dropdown - DigitalOcean - Google Cloud - Intune +- Jamf - Linode - Microsoft Azure - OpenStack @@ -27,8 +28,8 @@ Device42 discovery supports the following cloud types, as listed in the dropdown diff --git a/docs/auto-discovery/index.mdx b/docs/auto-discovery/index.mdx index 2e9c467c..b8174302 100644 --- a/docs/auto-discovery/index.mdx +++ b/docs/auto-discovery/index.mdx @@ -189,7 +189,7 @@ There is also a ping sweep tool built into Device42. Find it in the UI under **D The Device42 remote collector (RC) is a lightweight virtual appliance (a VM) that can be quickly deployed, for example, in places like a secure network segment. RCs can be selected to run autodiscovery jobs by simply choosing them when creating the job. Choose the desired RC from the **Remote Collector** dropdown when initially setting up a new autodiscovery job, or editing an existing discovery job. Most autodiscovery jobs that can be launched from the Device42 **Discovery** menu support running from a deployed RC. -For more information head to the dedicated [Remote Collector page](auto-discovery/remote-collector-rc.md). +For more information head to the dedicated [Remote Collector page](auto-discovery/remote-collector-rc.mdx). ## Scripts for Linux, Solaris, Windows, and Mac diff --git a/docs/auto-discovery/jamf-autodiscovery.mdx b/docs/auto-discovery/jamf-autodiscovery.mdx new file mode 100644 index 00000000..e4c1ce53 --- /dev/null +++ b/docs/auto-discovery/jamf-autodiscovery.mdx @@ -0,0 +1,81 @@ +--- +title: "Jamf Autodiscovery" +sidebar_position: 15.5 +--- + +import ThemedImage from '@theme/ThemedImage' +import useBaseUrl from '@docusaurus/useBaseUrl' + +Device42 supports [Jamf](https://www.jamf.com/) autodiscovery from v19.02 of the Main Appliance. Run a Jamf cloud autodiscovery job to bring in your Apple ecosystem data. + +## Jamf Autodiscovery Items + +Currently, Jamf autodiscovery retrieves data on the following: + +- Computers +- Mobile devices +- IP and MAC addresses +- Installed software and applications +- Extension attributes (Custom Fields) + +## Requirements for Jamf autodiscovery + +To run a Jamf autodiscovery job, you need to set the appropriate permissions in your Jamf account and provide your Jamf username and password when creating the job. + +### Permission Requirements + +A standard Jamf user account with read-all permissions is required for autodiscovery. The easiest way to grant read-all permissions is to create a standard user account with the **Auditor** privilege set. + +Alternatively, you can use a **Custom** privilege set with all-read permissions enabled. + +For information on standard accounts and privilege sets, see the [Jamf Pro User Accounts and Groups](https://learn.jamf.com/en-US/bundle/jamf-pro-documentation-current/page/Jamf_Pro_User_Accounts_and_Groups.html) documentation. + +### Authentication Requirements + +Your Jamf account username and password are required in the **Basic credentials** field of the **Add Cloud Autodiscovery** form. + +Your username and password are used to request a bearer token. Bearer token authentication is then used for subsequent requests. + +## Create a Jamf Autodiscovery Job + +Navigate to **Discovery > Cloud** and click **+ Add Cloud Autodiscovery**. Select **Jamf** from the **Type** dropdown menu. + + + +Optionally, add a **Customer for discovered devices:** + + + +### Run Now or Schedule the Job + +Scroll down to create a run schedule for the job. Create multiple schedules for the job with the **+ Add another Autodiscovery Schedule** button. + + + +To run the job immediately, click **Save** to add it to the list of Cloud autodiscovery jobs and then click **Run Now**. + + diff --git a/docs/auto-discovery/linux-based-autodiscovery-software.md b/docs/auto-discovery/linux-based-autodiscovery-software.md index d0cb9461..587b6299 100644 --- a/docs/auto-discovery/linux-based-autodiscovery-software.md +++ b/docs/auto-discovery/linux-based-autodiscovery-software.md @@ -3,7 +3,7 @@ title: "Linux Based Autodiscovery Software" sidebar_position: 17 --- -**Note:** Since v13.2, Device42 has supported Linux (and UNIX) based autodiscovery from within the main UI. If you are simply trying to run discovery against Linux or UNIX, see our [Linux and UNIX Server AutoDiscovery Instructions.](linux-unix-server-auto-discovery.mdx) or our [Remote Collector documentation](remote-collector-rc.md). If you want to use the standalone Linux discovery tools, continue reading below. +**Note:** Since v13.2, Device42 has supported Linux (and UNIX) based autodiscovery from within the main UI. If you are simply trying to run discovery against Linux or UNIX, see our [Linux and UNIX Server AutoDiscovery Instructions.](linux-unix-server-auto-discovery.mdx) or our [Remote Collector documentation](remote-collector-rc.mdx). If you want to use the standalone Linux discovery tools, continue reading below. # Linux Based Autodiscovery Software diff --git a/docs/auto-discovery/remote-collector-rc.md b/docs/auto-discovery/remote-collector-rc.md deleted file mode 100644 index d0e36bbe..00000000 --- a/docs/auto-discovery/remote-collector-rc.md +++ /dev/null @@ -1,116 +0,0 @@ ---- -title: "Remote Collector (RC)" -sidebar_position: 24 ---- - -## The Device42 Remote Collector (RC) - -The Remote Collector _(aka the "RC")_ is a virtual appliance that is deployed separately from the D42 main appliance _(aka Device42 "MA")_. It is sent autodiscovery jobs and controlled from the MA, executing those jobs remotely. All autodiscovery jobs, including Power SNMP jobs \[v14+\] are supported and can be run remotely on an RC! _\[Please note: Windows discovery requires at least one [Windows Discovery Service](getstarted/installation/windows-discovery-service-installation.md) ("WDS") instance be deployed\]._ - -You may configure an unlimited number of remote collector appliances as needed across your environment. RCs facilitate SNMP, IPMI, hypervisor and other auto discoveries across networks with only https access required, eliminating the need to open numerous ports up across network segments. - -### RC Sizing Recommendations - -For one RC per 1000 workloads, the sizing recommendations are: -- 2 vCPU -- 4GB RAM -- 50GB vDisk - -## RC Installation and Configuration - -To download the Remote Collector, head to our [Auto-Discovery tools download page.](https://www.device42.com/autodiscovery/); Click the Download button under "D42 Remote Collector", which should be found at the top of the page. - -We currently offer an `.OVF` image for direct download. Should your hypervisor not support the OVF VM image format, please contact support@device42.com and we'll will work with you to provide an image compatible with your hypervisor. Deploy the VM image to your hypervisor, boot it, and log in using the VM console or via SSH, Port 22. The default credentials for the Remote Collector are: - -``` -username: client -password: device42 -``` - -After logging in to the console, you will see the main console menu: - -![](/assets/images/D42-23170_RC-console-menu-3-18-06-DM.png) - -### Initial (first-boot) Network Config - -Upon initial installation, you will first need to configure your network settings so you can proceed with setup. A static IP is best as D42 can lose contact with an RC with a changing (dynamic) IP address. On the main console menu, choose "Network Interfaces" and press enter on the name of your interface to edit it. Use the space bar to un-select DHCP and assign a static IP address using the following screen. - -![](/assets/images/D42-23170_RC-edit-network-interface.png) - -**The "PREFIX" field above is asking for an integer that represents the subnet mask in slash notation, e.g. for 255.255.255.0, which is a /24, you will enter _24_.** Note that the PREFIX field has been removed and as soon as your RC connects to Device42, it will be updated. - -### Connect your RC to Device42 - -Each RC must be able to communicate with the main appliance on port 443. After initial communication, a WebSocket connection is established between the RC & MA on an ephemeral port (selected randomly), allowing full-duplex communication between them. The Device42 main appliance can thus talk to and control the RC over the WebSocket. - -From the main console menu, select "RC Setup" to register your RC with your main Device42 appliance. To do this, you will need to first generate a One Time Password (OTP) from Device42. Visit Device42 in your browser and via the main menu, head to _Discovery -> Remote Collectors_. Here you will be able to view any existing registered RCs and generate an OTP to register a new one: - -![](/assets/images/D42-23170_RC-list-page.png) - -Click "Generate OTP" in the top right and copy the password you receive. - -In the RC console, under "RC Setup" enter your OTP along with the IP address or FQDN of the main appliance: - -![](/assets/images/D42-23170_RC-setup-OTP.png) - -Once initial setup is complete, more detailed information about the RCs configuration is visible under the RC Setup sub-menu, including the option to reset and re-configure your RC. - -![](/assets/images/D42-23170_RC-setup-before-reset.png) - -After the initial registration on port 443, all subsequent communication occurs over a secure WebSocket channel between RC and MA. - -## View/Edit Remote Collector - -Click the Remote Collector _Name_ on the list page to view or edit a remote collector. Click the _Edit_ button to edit the RC. - -Note that the view and edit pages now includes a _MAC Address_ field showing the address of the RC. Be careful editing this address; an incorrect address will cause the RC to disconnect. - -![](/assets/images/D42-23170_RC-edit-page.png) - -### Remote Collector List Page Actions - -The Remote Collector list page Actions Menu contains commands you can use for selected collectors. - -![](/assets/images/D42-23170_RC-list-page-action-log-level-action-dd.png) - -![](/assets/images/D42-23170_RC-list-page-action-log-level.png) - -- **Delete with Detailed Confirmation** – Delete the selected RC(s) with a confirmation prompt. -- **Export Selected Items as CSV** – Export a CSV file with information about the selected RC(s). -- **Clear Logs** – Clear the log files for the selected RC(s). -- **Reboot Collectors** – Reboot the selected connected RC(s). Note that if your RC is exhibiting unusual behavior, rebooting the RC can be a good first step to resolving the problem. -- **Set Remote Collector Logging Level** – Set the RC logging level. Select _Information_ to reduce the log file size. (You can also set a Global Logging Level via the RC console.) - -![](/assets/images/D42-23170_RC-list-page-set-log-level-2.png) - -## Remote Collector Proxy Settings - -The proxy settings within the Main Appliance and RC are set independently but are often identical. To reduce the potential for error, the RC can pick up proxy settings that have been configured. You can view and edit the RC proxy settings within the RC view of the Main Appliance. - -## Scalability - -Device42 remote collectors provide robust scalability by offloading discovery workloads from you main appliance(s). You can deploy multiple remote collectors for each main appliance. Device42 recommends one remote collector with one WDS (Windows Discovery Service) for each 1,000 workloads. - -## Remote Collector (RC) Deployment Example - -Remote collectors are extremely flexible, and make discovery with Device42 easier than ever. You can deploy one or more, with no logical limit to the number of remote collectors. - -![main menu](/assets/images/D42_RC_deploy_example.png) - -In the deployment example pictured, a remote collector is deployed within each isolated DMZ Network Segment that, per firewall rules typical of a DMZ, the Device42 appliance is normally unable to directly reach and/or discover. Deploying a remote collector to these segments not only bolsters security by saving the Network Administrator from having to make multiple temporary (or permanent & insecure) firewall rules (_aka ‘holes’_) to allow discovery traffic to pass from the main appliance over the wide range of ports utilized by various vendors APIs. Please note that the diagram does not show the majority of network connectivity that would be present, and instead focuses mainly on what is discovered by the MA vs. the RC, and the communication between the RC & MA. - -Instead, as mentioned briefly in the introduction, all communication and discovery information is securely transmitted between the RC and the MA once a connection is established via Port 443 (HTTPS/SSL). This means a single, secure and easily monitored 1:1 rule allows for comprehensive and continuous discovery of the secured network segment \[as often as scheduled or desired\] - without compromising its isolation or security. - -## Running Remote Discoveries - -Once registered, you can now schedule any autodiscovery jobs from the main appliance, instructing them to run on the remote collectors of your choosing. Each autodiscovery screen now shows a “Remote Collector” drop-down menu. Clicking this box will display all registered Remote Collectors, and allows you to choose the RC you would like the discovery to run from: - -![Add SNMP autodiscovery and select Remote Collector](/assets/images/Add-SNMP-autodisc-RC-v15.PNG) - -## Updating your Remote Collector (RC) - -Device42 Remote Collectors (RCs) are updated automatically as long as they are connected to a Device42 main appliance (MA) instance. Updates to the Device42 MA instance include updates to your Remote Collector(s), and those updates are pushed out automatically as part of the Device42 update process you're used to. Thus, by keeping your main Device42 instance up to date, your can assure your remote collectors will are up to date as well! - -## Migrating Existing Power Appliance Jobs to a Remote Collector (RC) - -Migrating jobs that were created for the original standalone power appliance is possible with existing tools. Simply follow the [existing power job migration guide here](../infrastructure-management/power-and-environmental-monitoring/power-rc-setup-job-migration.md) to migrate jobs to the new RC of your choice. diff --git a/docs/auto-discovery/remote-collector-rc.mdx b/docs/auto-discovery/remote-collector-rc.mdx new file mode 100644 index 00000000..e08b216f --- /dev/null +++ b/docs/auto-discovery/remote-collector-rc.mdx @@ -0,0 +1,153 @@ +--- +title: "Remote Collector (RC)" +sidebar_position: 24 +--- + +import ThemedImage from '@theme/ThemedImage' +import useBaseUrl from '@docusaurus/useBaseUrl' + +## The Device42 Remote Collector (RC) + +The Remote Collector (RC) is a virtual appliance that is deployed separately from the Device42 Main Appliance (MA). The RC is sent autodiscovery jobs and controlled from the MA, executing those jobs remotely. All autodiscovery jobs, including Power SNMP jobs, are supported and can be run remotely on an RC. + +:::note +Windows discovery requires at least one [Windows Discovery Service](getstarted/installation/windows-discovery-service-installation.md) (WDS) instance to be deployed. +::: + +You may configure an unlimited number of RC appliances as needed across your environment. RCs facilitate SNMP, IPMI, hypervisor, and other autodiscoveries across networks requiring only HTTPS access, eliminating the need to open numerous ports up across network segments. + +### RC Sizing Recommendations + +For one RC per 1000 workloads, the sizing recommendations are: +- 2 vCPU +- 4GB RAM +- 50GB vDisk + +## RC Installation and Configuration + +To download the RC, head to our [**Autodiscovery** tools download page](https://www.device42.com/autodiscovery/). In the **D42 Remote Collector (RC)** section at the top of the page, click the **Download** button. + +We currently offer an `.OVF` image for direct download. Should your hypervisor not support the OVF virtual machine (VM) image format, please contact [support@device42.com](mailto:support@device42.com) and we will work with you to provide an image compatible with your hypervisor. Deploy the VM image to your hypervisor, boot it, and log in via the VM console or SSH, Port 22. + +The default credentials for the RC are: + +Username: + ``` + client + ``` +Password: + ``` + device42 + ``` + +After logging in to the console, you will see the main console menu: + +![](/assets/images/D42-23170_RC-console-menu-3-18-06-DM.png) + +### Initial (First-Boot) Network Config + +Upon initial installation, configure your network settings to proceed with setup. It is best to use a static IP for your network, as Device42 can lose contact with RCs that have changing (dynamic) IP addresses. + +On the main console menu, choose **Network Interfaces** and press `enter` on the name of your interface to edit it. Use the `space bar` to unselect DHCP and assign a static IP address using the following screen. + +![](/assets/images/D42-23170_RC-edit-network-interface.png) + +The **PREFIX** field above asks for an integer that represents the subnet mask in slash notation. For example, for `255.255.255.0`, which is a `/24`, you would enter `24`. Note that the **PREFIX** field has been removed, and as soon as your RC connects to Device42, it will be updated. + +### Connect your Remote Collector to Device42 + +Each RC must be able to communicate with the main appliance on port 443. After initial communication, a WebSocket connection is established between the RC and MA on an ephemeral port (selected randomly), allowing full-duplex communication between them. The Device42 main appliance can thus talk to and control the RC over the WebSocket. + +From the main console menu, select **RC Setup** to register your RC with your main Device42 appliance. To do this, you will need to first generate a One Time Password (OTP) from Device42. Visit Device42 in your browser and via the main menu, head to **Discovery > Remote Collectors**. Here you will be able to view any existing registered RCs and generate an OTP to register a new one: + + + +Click **Generate OTP** in the top right and copy the password you receive. + +In the RC console, under **RC Setup** enter your OTP along with the IP address or FQDN of the Main Appliance: + +![](/assets/images/D42-23170_RC-setup-OTP.png) + +When the initial setup is complete, more detailed information about the configuration of the RC is visible under the **RC Setup** submenu, including the option to reset and reconfigure your RC. + +![](/assets/images/D42-23170_RC-setup-before-reset.png) + +After the initial registration on port 443, all subsequent communication occurs over a secure WebSocket channel between RC and MA. + +## View and Edit Remote Collectors + +Click the RC **Name** on the list page to view or edit a specific RC. Click the **Edit** button to edit the RC. + +Note that the view and edit pages now includes a **MAC Address** field showing the address of the RC. Be careful editing this address; an incorrect address will cause the RC to disconnect. + +![](/assets/images/D42-23170_RC-edit-page.png) + +### Remote Collector List Page Actions + +Navigate to the RC list page under **Discovery > Remote Collectors** for the **Select an action** dropdown menu. + + + +Select RC(s) from the table, choose one of the following actions, and click the hammer icon to execute the action: + +- **Delete with Detailed Confirmation**: Delete the selected RC(s) with a confirmation prompt. +- **Export Selected Items as CSV**: Export a CSV file with information about the selected RC(s). +- **Clear logs**: Clear the log files for the selected RC(s). +- **Reboot Collectors**: Reboot the selected connected RC(s). Note that if your RC is exhibiting unusual behavior, rebooting the RC can be a good first step to resolving the problem. +- **Set Remote Collector Logging Level**: Set the RC logging level. Select **Information** to reduce the log file size. You can also set a Global Logging Level via the RC console. + + + +## Remote Collector Proxy Settings + +The proxy settings within the MA and RC are set independently but are often identical. To reduce the potential for error, the RC can pick up proxy settings that have been configured. You can view and edit the RC proxy settings within the RC view of the MA. + +## Scalability + +Device42 RCs provide robust scalability by offloading discovery workloads from your MA. You can deploy multiple remote collectors for each main appliance. Device42 recommends one remote collector with one Windows Discovery Service for every 1,000 workloads. + +## Remote Collector Deployment Example + +Remote collectors are extremely flexible, and make discovery with Device42 easier than ever. You can deploy one or more, with no logical limit to the number of remote collectors. + +![main menu](/assets/images/D42_RC_deploy_example.png) + +In the deployment example pictured, an RC is deployed within each isolated DMZ Network Segment that, per firewall rules typical of a DMZ, the Device42 appliance is normally unable to directly reach or discover. Deploying a remote collector to these segments bolsters security by saving the Network Administrator from making multiple temporary (or permanent and insecure) firewall rules (aka ‘holes’) to allow discovery traffic to pass from the MA over the wide range of ports used by various vendor APIs. + +Please note that the diagram doesn't show the majority of network connectivity that would be present, and instead focuses mainly on what is discovered by the MA vs. the RC, and the communication between the RC and MA. + +As mentioned briefly in the introduction, all communication and discovery information is securely transmitted between the RC and the MA once a connection is established via Port 443 (HTTPS/SSL). This means a single, secure, and easily monitored 1:1 rule allows for comprehensive and continuous discovery of the secured network segment - as often as scheduled or desired - without compromising its isolation or security. + +## Running Remote Discoveries + +Once registered, you can schedule any autodiscovery job from the MA and instruct it to run on the remote collector of your choosing. Each autodiscovery screen shows a **Remote Collector** dropdown menu. Click this box to display all registered RCs and choose the RC you would like the discovery job to run from: + +![Add SNMP autodiscovery and select Remote Collector](/assets/images/Add-SNMP-autodisc-RC-v15.PNG) + +## Updating Your Remote Collector + +Device42 RCs are updated automatically as long as they are connected to a Device42 MA. Updates to the MA instance include updates to your RC(s), and those updates are pushed out automatically as part of the regular Device42 update process. By keeping your main Device42 instance up to date, can ensure your RCs are up to date as well. + +## Migrating Existing Power Appliance Jobs to a Remote Collector + +Migrating jobs that were created for the original standalone power appliance is possible with existing tools. + +Follow the [Power Job Migration Guide](../infrastructure-management/power-and-environmental-monitoring/power-rc-setup-job-migration.md) to migrate jobs to the new RC of your choice. diff --git a/docs/auto-discovery/resource-utilization-overview.md b/docs/auto-discovery/resource-utilization-overview.md index e1c5d6cd..88918b3c 100644 --- a/docs/auto-discovery/resource-utilization-overview.md +++ b/docs/auto-discovery/resource-utilization-overview.md @@ -5,29 +5,31 @@ sidebar_position: 25 ## What is Resource Utilization? -Device42's _Resource Utilization_ features \[_aka 'RU', the "enable monitoring for discovered devices" setting_\] are enabled for users with an installed RU license. This powerful module allows for the collection and examination of server resource usage metrics, which can fuel advanced business and capacity planning decisions as well as migration planning, move-group selection (via Affinity Groups), cloud target rightsizing, and support a variety of other digital transformation projects, as well. +Device42's Resource Utilization (RU) features are enabled for users with an installed RU license. RU is also known as the "enable monitoring for discovered devices" setting. This powerful module collects and examines server resource usage metrics, which can fuel advanced business and capacity-planning decisions, migration planning, move-group selection (via Affinity Groups), and cloud-target rightsizing, as well as support a variety of other digital transformation projects. -Once enabled, you will see a 'monitoring' option on the Hypervisor/\*NIX/Windows Discovery settings screen, and stats are currently displayed on Linux and Windows-based platform CIs. +Once enabled, you will see a 'monitoring' option on Hypervisor/\*nix/Windows autodiscovery jobs. On Linux and Windows-based platform CIs, stats are currently displayed. ![](/assets/images/D42-22008_RU-sampling-interval-700x420.png) **Resource utilization is only available and will only function if:** -- The licensing module is enabled - on/off -\[the enable checkbox (pictured above) will be disabled if the licensing module is disabled\] -- Resource Utilization Tracking Checkbox is checked at time of discovery -- Verify monitoring option is checked after the device has been discovered (assuming the job is set to run again -- but verify when the schedule is set and next time its run, it should bring in data) +- The licensing module is enabled. Check whether **Resource Utilization** is **Enabled** under **Tools > Settings > Licensing**. The **Enable Resource Utilization Tracking for Device(s)** checkbox (pictured above) will be disabled if the licensing module is disabled. +- The **Enable Resource Utilization Tracking for Device(s)** is checked at the time of discovery on a discovery job. +- The **Is Device42 monitoring enabled** option is set as **Yes** after a device has been discovered. If the job is scheduled to run again, it should bring in data the next time the discovery job runs. * * * -## Handling of the same IP/machine instance across multiple RCs +## Handling of the Same IP/Machine Instance Across Multiple RCs -If an IP is discovered across multiple RCs, Device42 will _not_ monitor that IP again if it is already being monitored; were this otherwise permitted, unexpected behavior would likely result. We will adjust this and other RU workflows based on user feedback - please do let us know about any ideas or changes you have that would help you! +If an IP is discovered across multiple Remote Collectors (RCs), Device42 will **not** monitor that IP again if it is already being monitored; were this otherwise permitted, unexpected behavior would likely result. We will adjust this and other RU workflows based on user feedback - please do let us know about any ideas or changes you have that would help you! -### Monitoring management - Example scenarios +### Monitoring Management - Example Scenarios -Let’s consider three Devices A, B and C, and two Remote Collectors, RC#1 & #2. Monitoring is currently _disabled_ on all three. +Consider the following scenario: -Consider a scenario where two discovery jobs are configured: +You have three Devices, A, B, and C, and two RCs, RC#1 and #2. Monitoring is currently **disabled** on all three. + +Two discovery jobs are configured: 1. Job#1 includes Device A and Device B 2. Job#2 includes Device B and Device C @@ -52,19 +54,19 @@ Then you change the settings on Job #2 and run it from RC#2 with monitoring enab - DeviceB with monitoring on RC#1 - DeviceC with monitoring on RC#2 -Note that _DeviceB_ does not switch which RC it's attached to! +Note that DeviceB does not switch the RC that it's attached to. * * * -### How can I switch device RU monitoring to another RC +### How Can I Switch Device RU Monitoring to Another RC? -If you _want_ to move a device to another RC, this can be accomplished by opening the device list, selecting the device, and setting the `Disable monitoring…` option. After disabling monitoring, re-run the job yet again with monitoring re-enabled on the new target RC. +If you _want_ to move a device to another RC, open the device list, select the device, and select one of the **Disable monitoring for selected devices...** actions. After disabling monitoring, run the job again with monitoring re-enabled on the new target RC. ![Disable RU Monitoring on devices](/assets/images/disable_RU_monitoring_device_list_view-1.png) -The difference between the options deal with the handling of historical data for the device in question. If “Keep Data” is selected, data is stored for as long as is needed, and if the same device were rediscovered, the existing data will be automatically utilized. The second option simply deletes all existing data from the server. When a previously existent device is re-discovered with the second option selected, its history begins anew. +The options differ according to how they handle the historical data for the device in question. The **...but keep data** action stores data for as long as needed, so that if the same device were rediscovered, the existing data would be automatically utilized. The **...and delete data** option simply deletes all existing data from the server. When a previously existent device is rediscovered with this option selected, its history begins anew. -Now re-run Job#2 on RC#2 with monitoring enabled once again. After that run, you can see the device has moved to RC2: +Now rerun Job#2 on RC#2 with monitoring enabled once again. After that run, you can see the device has moved to RC2: - DeviceA with monitoring on RC#1 - DeviceB with monitoring on RC#2 @@ -72,52 +74,54 @@ Now re-run Job#2 on RC#2 with monitoring enabled once again. After that run, you * * * -## Technical Details: RU data storage +## Technical Details: RU Data Storage -### The time-series database \[TSDB\] +### The Time-Series Database (TSDB) Monitoring data is kept on the RC in a TSDB. A dedicated database called `sensors` is used for this purpose, and it contains the following series: -- **infeeds** - stores infeeds stats -- **outlets** - stores outlets stats -- **banks** - stores banks stats -- **battery** - stores battery stats -- **device** - stores device sensors - usually load, power factor, etc. -- **env\_sensor** - stores all types of device\_sensors - humidity, temperature, cpu, etc. +- **`infeeds`**: Stores infeeds stats +- **`outlets`**: Stores outlets stats +- **`banks`**: Stores banks stats +- **`battery`**: Stores battery stats +- **`device`**: Stores device sensors - usually load, power factor, etc. +- **`env_sensor`**: Stores all types of `device_sensors` - humidity, temperature, CPU, etc. -You can think about these series as if they were Excel sheets, in which the first column is always a timestamp. For example, a memory series looks like this: +You can think about these series as if they were Excel sheets, with the first column always consisting of a timestamp. For example, a memory series looks like this: ![A memory series in Device42](/assets/images/sensor_data_series.png) -In general, chart generation doesn't use all data points, as there tends to be quite a lot of them \[_for example, a 30 sec. interval for a month = 86,400 data points_\]. Instead, data is aggregated, which is a common way to visualize data of this type. +In general, charts don't use all the data points, as there tend to be quite a lot of them. For example, a 30-second interval used for a month would generate 86,400 data points. Instead, data is aggregated, which is a common way to visualize data of this type. -Aggregation takes multiple data points and converts their values to one depending on the selected aggregation function. Currently, Device42 does this one of three ways: _MIN, AVG,_ and _MAX_. +Aggregation takes multiple data points and converts their values to one data point, depending on the selected aggregation function. Currently, Device42 does this one of three ways: `MIN`, `AVG`, or `MAX`. * * * -
As an example, to generate AVG physical values from 5 minutes intervals with a point every minute from the table in the screenshot above, we will get:The MIN setting, instead, would return the smallest value from each set:
  • (53.242 + 51.672) / 2 = 52.457
  • (52.688 + 52.676) / 2 = 52.682
  • 53.242 < 51.672 = 51.672
  • 52.688 > 52.676 = 52.676
+
As an example, if we were to generate `AVG` physical values from 5-minute intervals, with a point every minute, from the table in the screenshot above, we would get:The `MIN` setting, instead, would return the smallest value from each set:
  • (53.242 + 51.672) / 2 = 52.457
  • (52.688 + 52.676) / 2 = 52.682
  • 53.242 < 51.672 = 51.672
  • 52.688 > 52.676 = 52.676
* * * -### What happens if an RC is down? +### What Happens if an RC Is Down? -When an RC is down, no data will be shown as RC must be responsive to queries for data. Charts/reports will show empty gaps in data for periods where RCs were down. +When an RC is down, no data will be shown, as the RC must be responsive to queries for data. Charts and reports will show empty gaps in data for periods when RCs were down. ### Data Capture Intervals Available intervals: -\- SNMP: 1 second - Linux: 5 seconds - Windows: 15 seconds +- SNMP: 1 second +- Linux: 5 seconds +- Windows: 15 seconds ### Data Visualization -To visualize data, choose the _“Trends”_ option from the **\[...\]** (aka "Ellipse") menu in the upper-right hand corner of any device that has RU enabled. +To visualize data, choose the **Trends** option from the **...** (ellipsis) menu in the upper-right-hand corner of any device that has RU enabled. -Note that this option will not be displayed if monitoring is not active and/or the license does not allow it: +Note this option will not be displayed if monitoring is not active or the license does not allow it: ![Trends menu item ellipse button](/assets/images/trends_button_ellipse_menu.png) -Note that device\_sensors will also be shown here for those users that have power monitoring enabled, as well. +Note that `device_sensors` will also be shown here for those users that have power monitoring enabled. * * * @@ -125,117 +129,130 @@ Note that device\_sensors will also be shown here for those users that have powe ### CPU -- **CPU**: the mathmatical mean of `CPU-1...N` loads, expressed as a percent -- **CPU-1...N**: is the real CPU load as a percent +- **`CPU`**: The mathematical mean of `CPU-1...N` loads, expressed as a percentage +- **`CPU-1...N`**: The real CPU load as a percentage ### Memory -- **Total**: sum of physical and swap in megabytes -- **Physical**: RAM used in megabytes -- **Swap**: swap/page file used in megabytes +- **`Total`**: Sum of physical and swap in megabytes +- **`Physical`**: RAM used in megabytes +- **`Swap`**: Swap/page file used in megabytes ### Disks -- **Name**: name of the HDD -- **WriteLatency**: latency of the write operations in ms -- **WriteIORate**: speed of the write operations in MB/s -- **WriteIOPS**: number of write operations per second -- **WriteTransfer**: raw number of bytes written to disk -- **ReadLatency**: latency of the read operations in ms -- **ReadIORate**: speed of the read operations in MB/s -- **ReadIOPS**: number of read operations per second -- **ReadTransfer**: raw number of bytes read from disk +- **`Name`**: Name of the HDD +- **`WriteLatency`**: Latency of the write operations in ms +- **`WriteIORate`**: Speed of the write operations in MB/s +- **`WriteIOPS`**: Number of write operations per second +- **`WriteTransfer`**: Raw number of bytes written to disk +- **`ReadLatency`**: Latency of the read operations in ms +- **`ReadIORate`**: Speed of the read operations in MB/s +- **`ReadIOPS`**: Number of read operations per second +- **`ReadTransfer`**: Raw number of bytes read from disk ### Network -- **Name**: name of the adapter -- **InSpeed**: download speed in MB/s -- **InTransfer**: raw number of bytes received by adapter -- **OutSpeed**: upload speed in MB/s -- **OutTransfer**: raw number of bytes transmitted by adapter +- **`Name`**: Name of the adapter +- **`InSpeed`**: Download speed in MB/s +- **`InTransfer`**: Raw number of bytes received by adapter +- **`OutSpeed`**: Upload speed in MB/s +- **`OutTransfer`**: Raw number of bytes transmitted by adapter -For the most part, Device42 will display _aggregated values_. +For the most part, Device42 will display **aggregated values**. The only exception to this in v1 is for `Transfer` values. They are written as raw numbers and are constantly growing so there is logic behind the display of the values themselves. Instead, the difference for a given interval is displayed:
So, let’s look at the following example data for ReadTransfer:
  • 00:01 – 100 bytes
  • 00:02 – 123 bytes
  • 00:03 – 234 bytes
If a user requests data between 00:01 and 00:03 with density=3 (see API section for density details), Device42 will print:
  • 00:01 – 0 bytes
  • 00:02 – 23 bytes
  • 00:03 – 111 bytes
-If results cannot be retreived from an RC (e.g. the RC is down, etc.), an “Inaccessible Remote Collector” message will be displayed on trend reports. +If results cannot be retrieved from an RC (if the RC is down, etc.), an **Inaccessible Remote Collector** message will be displayed on trend reports. * * * ## Reporting -There are three types of Resource Utilization data reports available via _Reports -> "Legacy Reporting"_ based on captured RU data. +There are three types of RU data reports available via **Analytics > Reports** based on captured RU data. **Users may select the "Type of Data" they would like to see:** -- _Minimum_ - Report uses data minimums. -- _Maximum_ - Report uses data maximums. -- _Average_ - Report uses data averages. +- **Minimum**: Report uses data minimums +- **Maximum**: Report uses data maximums +- **Average**: Report uses data averages -**Peak \[Maximum\] calculations:** +**Peak (Maximum) calculations:** -- _CPU_ - A single # that represents the sum of all _(cpu power times percentage peak usage)_ -- _Memory_ - Total Peak, RAM, Swap and RAM + Swap -- _Network_ - Peak per card -- _Disk_ - Peak IO across disks and Peak latency +- **CPU**: A single number that represents the sum of all (CPU power times percentage peak usage) +- **Memory**: Total Peak, RAM, Swap, and RAM + Swap +- **Network**: Peak per card +- **Disk**: Peak IO across disks and Peak latency * * * ## APIs -Currently, this API endpoint provides results in CSV format; \[JSON format may be implemented in the future\]: +Currently, this API endpoint provides results in CSV format. JSON format may be implemented in the future: `/service/data/v1.0/trends/?id=2714&metric=AVG&timezoneoffset=-180&timeperiod=3&density=110&end_date=09%2F24%2F17+21%3A17%3A24` -### General API parameters +### General API Parameters + +- **`type`**: Type of report, currently supports only device. _Optional_. +- **`id`**: Device ID +- **`ids`**: Comma-separated list of IDs. _Optional_. +- **`metric`**: The aggregation function that will be used. Can be `AVG`, `MIN`, or `MAX`. +- **`timezoneoffset`**: Your time zone is represented by GMT offset in minutes. For Moscow it is -180 (minus) and for NY 240 (without plus) +- **`end_date`**: The date of the final data point in US date and 24H time format, 12/31/17 15:16:17. +- **`timeperiod`**: The number of hours that you want to observe. -- **type** - type of report, currently supports only device. _\[Optional\]_. -- **id** - device ID -- **ids** - comma separated list of IDs. Optional. -- **metric** - is actually aggregation function that will be used. Can be AVG, MIN, MAX. -- **timezoneoffset** - is your TZ GMT offset in minutes. For Moscow it is -180 (minus) and for NY 240 (without plus) -- **end\_date** - is the date of the final data point in format: 12/31/17 15:16:17 (US date + 24H time) -- **timeperiod** - is the number of hours that you want to observe. +### Possible Values: -### Possible values: +Pass an integer, `1-9`, to represent the following values: -Pass an integer, 1-9, to represent the following values: +| Value | Time Interval | +|-------|-----------------| +| `1` | 30 minutes | +| `2` | 1 hour | +| `3` | 3 hours | +| `4` | 6 hours | +| `5` | 12 hours | +| `6` | 24 hours | +| `7` | 7 days | +| `8` | 31 days | +| `9` | 183 days | -- Pass the value 1 for `30` minutes -- Pass 2 thru 6 = `1`, `3`, `6`, `12`, or `24` hours, respectively -- or pass 7, 8, or 9 = `7` days, `31` days, and `183` days -### Data points control parameters +### Data Points Control Parameters -For data points control, you should use one of these parameters. Choose one or the other, as trying to use both will cause one to override the other. +To control the number of data points, use the `interval` or `density` parameter. Choose one or the other, as trying to use both will cause one to override the other. -- **interval** - specify the number of seconds between data points. If you want to get AVG/MIN/MAX data at 5 minute intervals for last 24 hours, set _interval=300_ and you will receive 288 data points. -- **density** - the number of the points to collect per interval. This is similar to interval but you should use it if you want to get exact number of the points for given interval. If you will use time period=6 (24 hours) and density=100. You will get 100 points with interval ~14.5 minutes. With density 1000 you will get 1000 points - with 1.5 interval. +- **`interval`**: Specify the number of seconds between data points. For example, if you want to get AVG/MIN/MAX data at 5-minute intervals for the last 24 hours, set `interval=300` and you will receive 288 data points. +- **`density`**: The number of points to collect per interval. This is similar to `interval`, but you should use it if you want to get an exact number of points for a given interval. For example, if you use a time of `period=6` (24 hours) and `density=100`, you will get 100 points with an interval of approximately 14.5 minutes. With a density of 1000, you will get 1000 points with a 1.5-minute interval. -There is an important limitation for both control parameters. If the device polling interval is N seconds, and N > interval, the RC will reset interval to N. For example, if the polling interval for device is 15 seconds and you set density=1000 & period=1 (30 min) you will not get 1000 points. You will get 30 min \* 60 second = 1800 sec / 15 sec polling interval = 120 points. +**Important Limitation**: If the device polling interval is `N` seconds, and `N > interval`, the RC will reset `interval` to `N`. For example, if the polling interval for the device is 15 seconds, and you set `density=1000` and `period=1` (30 min), you will not get 1000 points. Instead, you will get `30 min * 60 seconds = 1800 seconds / 15 seconds polling interval = 120 points`. **CSV contains next type-measure combinations of data:** -- **CPU-load** - aggregated CPU load for selected interval in % (for CPU without number it is averaged for all numbered CPUs) -- **Mem-physical** - aggregated physical memory used -- **Mem-swap** - aggregated swap used -- **Disk-(total,write,read)\_iops** - aggregated iops for disk -- **Disk-(total,write,read)\_iorate** - aggregated iorate for disk -- **Disk-(total,write,read)\_latency** - aggregated latency or disk -- **Disk-(total,write,read)\_transfer** - raw transfer for disk at the end of the interval -- **Disk-(total,write,read)\_transfer\_diff** - difference between raw transfer at end and start of interval -- **Nic-(in,out)\_speed** - aggregated speed for interface -- **Nic-(in,out)\_transfer** - raw transfer for operation disk at the end of the interval -- **Nic-(in,out)\_tranfer\_diff** - difference between raw transfer at end and start of interval +- **`CPU-load`**: Aggregated CPU load for the selected interval as a percentage (for CPUs without a number, it is averaged across all numbered CPUs) +- **`Mem-physical`**: Aggregated physical memory used +- **`Mem-swap`**: Aggregated swap used +- **`Disk-(total,write,read)_iops`**: Aggregated IOPS for the disk +- **`Disk-(total,write,read)_iorate`**: Aggregated IORate for the disk +- **`Disk-(total,write,read)_latency`**: Aggregated latency for the disk +- **`Disk-(total,write,read)_transfer`**: Raw transfer for the disk at the end of the interval +- **`Disk-(total,write,read)_transfer_diff`**: Difference between raw transfer at the end and the start of the interval +- **`Nic-(in,out)_speed`**: Aggregated speed for the interface +- **`Nic-(in,out)_transfer`**: Raw transfer for the network interface at the end of the interval +- **`Nic-(in,out)_transfer_diff`**: Difference between raw transfer at the end and at the start of the interval + +### What if My RC Is Offline? -### What if my RC is offline? +If your target RC is offline, you will not be able to fetch data from it. All fields will either come back empty or will display the `-` character. Charts, too, will be empty. One exception is the PDU main page, which will display the latest values because its data is cached. -If your target Remote Collector is offline, you will not be able to fetch data from it. All fields will either come back empty or will display the `-` character. Charts, too, will be empty. One exception is the PDU main page, which will display the latest values because its data is cached. +### RU Note: Use Static IP Addresses -### RU Note: Use STATIC IP addresses! +If an RC and the Windows discovery service are both using DHCP IPs, automated IP changes can break the connection between them, and therefore affect running jobs, etc. -If an RC and the Windows discovery service are both using DHCP IPs, automated IP changes can break the connection between them, and therefore effect running jobs etc. It is _STRONGLY recommended_ that STATIC IPs be used for all Device42 appliances, RCs, etc. +:::warning +We strongly recommended that **static** IP Addresses be used for all Device42 appliances, RCs, etc. +::: -In the case that DHCP does break a connection, re-run the discovery job to resume monitoring. DHCP IP addresses are **NOT** a supported configuration. +In the case that DHCP does break a connection, rerun the discovery job to resume monitoring. DHCP IP addresses are **not** a supported configuration. diff --git a/docs/auto-discovery/sccm-discovery-net-tool.md b/docs/auto-discovery/sccm-discovery-net-tool.md index 9e820237..b74db6e5 100644 --- a/docs/auto-discovery/sccm-discovery-net-tool.md +++ b/docs/auto-discovery/sccm-discovery-net-tool.md @@ -4,42 +4,38 @@ sidebar_position: 26 --- :::note -THIS TOOL WILL BE DEPRECATED in the near future. With v18.11.00 of Device42 and functionality of SCCM integration will be available natively from Device42, or using the WDS service. You can continue to use the tool for now, but we recommend that you cut over to the native functionality. +This tool will be deprecated in the near future. From v18.11.00 of Device42, SCCM integration is available natively from the Device42 Main Appliance, or using the WDS service. You can continue to use the tool for now, but we recommend that you use the native functionality. Please see our new [SCCM documentation](auto-discovery/sccm-discovery.mdx). ::: -_The Auto Discovery Client is an external tool \[.NET based\] that runs on Windows machines, either standalone or as a service. It auto-discovers detailed information about Windows Servers, Linux / UNIX / \*nix Servers, Hyper-V Hypervisor, and Virtual Machine Guest inventories, and can also import CI data \[API –> API\] from Microsoft SCCM Instances._ +The autodiscovery client is a .NET-based external tool that runs on Windows machines, either standalone or as a service. It autodiscovers detailed information about Windows Servers, Linux, UNIX, *nix Servers, Hyper-V Hypervisors, and Virtual Machine guest inventories, and can also import Configuration Item (CI) data, via API to API, from Microsoft SCCM Instances.   * * * -### SCCM Information +## SCCM Information If you are already using SCCM in your environment or are planning to use it, the Device42 SCCM integration can automatically sync the hardware and software inventory (CI) data to Device42. -#### SCCM Permissions +### SCCM Permissions -The user account you supply must have permission to access the SCCM instance. You can add a user in SCCM under “Administration”; Choose “Administrative Users”. The user we tested within the lab was an SCCM Admin, but the “Read-only Analyst” role should be plenty, as it “Grants Permissions to view all Configuration Manager Objects”, and the import is a _read-only_ operation from the SCCM perspective. - -  - -* * * +The user account you supply must have permission to access the SCCM instance. You can add a user in SCCM under **Administration** and choose **Administrative Users**. The user we tested within the lab was an SCCM Admin, but the “Read-only Analyst” role should be plenty, as it “Grants Permissions to view all Configuration Manager Objects”, and the import is a read-only operation from the SCCM perspective. ### .NET Tool Installation -You must contact the Device42 Support team ([support@device42.com](mailto:support@device42.com)) to get access to the Discovery Client software. +You must contact the Device42 Support team [support@device42.com](mailto:support@device42.com) to get access to the Discovery Client software. -Installation requirements and instructions for setting up auto discovery client. +Installation requirements and instructions for setting up the autodiscovery client. -1. Install the Microsoft .NET Framework 4. There is a Standalone Installer available at: https://www.microsoft.com/en-us/download/details.aspx?id=17718 -2. To install the Autodiscovery client, please contact the Device42 Support team ([support@device42.com](mailto:support@device42.com)). +1. Install the [Microsoft .NET Framework 4 (Standalone Installer)](https://www.microsoft.com/en-us/download/details.aspx?id=17718). +2. To get the autodiscovery client, please contact the Device42 support team [support@device42.com](mailto:support@device42.com). -After running the installation, you can find the application in your Start Menu. +After running the installation, you can find the application in your **Start Menu**. -#### Silent Installation +### Silent Installation -The silent install will fail if, for whatever reason, it is unable to successfully stop the service in a short time period. If a discovery is running, the service will not stop until the discovery can be gracefully terminated (which could take a bit of time). The solution is to stop the service, and then wait; if the process is still running, kill it and then proceed with the installation. +The silent installation will fail if, for whatever reason, it is unable to successfully stop the service in a short time period. If a discovery is running, the service will not stop until the discovery can be gracefully terminated, which could take a bit of time. The solution is to stop the service and wait; if the process is still running, kill it and then proceed with the installation. The key here is to ensure the process is not running when you attempt to run the silent installation. @@ -47,77 +43,75 @@ The key here is to ensure the process is not running when you attempt to run the * * * -### Settings +## The Settings Tab -Under the Settings tab, you will have sections for System, Credentials, and Exclusions. +Under the **Settings** tab, you will see the **System**, **Credentials**, and **Exclusions** sections. -#### System Sub-Menu - Device42 System Settings +### System Sub-Menu - Device42 System Settings -##### Device42 Settings: - -You can enter your Device42 credentials here to allow the application to upload the auto-discovered data directly to Device42. +You can enter your Device42 credentials here to allow the application to upload the autodiscovered data directly to Device42. ![Device42 Config](/assets/images/autodiscovery-01.png) -##### System Settings: +### System Settings: -The Task Threads value allows you to limit the amount of task threads the application will spawn during autodiscovery. You can use this to reduce the strain on your network if you are concerned about scanning a higher amount of systems. +The **Task Threads** value allows you to limit the number of task threads the application will spawn during autodiscovery. You can use this to reduce the strain on your network if you are concerned about scanning a higher amount of systems. -##### Ignore Settings: +### Ignore Settings: You can choose to ignore common services, software, and software patterns to avoid pulling in services or software that are typically not tracked by users. The lists used are available at https://github.com/device42/AutoDiscoverIgnoreFiles -#### Credentials Sub-Menu +### Credentials Sub-Menu -By choosing “New” from the dropdown you will be able to define all the credentials to be used in the autodiscovery process. For Windows credentials you can enter a local or domain user who has privileges to execute Remote WMI calls. You can also opt to use the current credentials of the logged in user. +Choose **New** from the dropdown to define all credentials to be used in the autodiscovery process. For Windows credentials, you can enter a local or domain user who has privileges to execute Remote WMI calls. You can also opt to use the current credentials of the logged-in user. ![Device42 Credentials](/assets/images/autodiscovery-02.png) You can enter a test address to verify that a server is accessible from the autodiscovery application. -#### Exclusions Sub-Menu +### Exclusions Sub-Menu ![Device42 Exclusions](/assets/images/autodiscovery-03.png) -#### Ports +### Ports -You can use the Exclusions section to list listening or remote ports that you would like excluded from autodiscovery. For instance, adding port 22 to the excluded Unix ports will exclude adding the service port for ssh if you are not interested in seeing ssh connections in Device42. +Use the **Exclusions** sub-menu to list listening or remote ports that you would like excluded from autodiscovery. For example, if you are not interested in seeing SSH connections in Device42, adding port 22 to the excluded Unix ports will exclude the service port for SSH. -#### Remote Connections +### Remote Connections -You can exclude remote connections by IP address and port as well. This is convenient if there are known connections to any of your devices that you are not interested in bringing in to Device42. +You can exclude remote connections by IP address and port as well. This is convenient if there are known connections to any of your devices that you are not interested in bringing into Device42. * * * -### Discovery +## The Discovery Section -The Discovery section will allow you to setup and save multiple autodiscovery jobs. +The **Discovery** section will allow you to set up and save multiple autodiscovery jobs. ![Device42 AutoDiscovery](/assets/images/autodiscovery-04.png) -#### Discovery Settings +### Discovery Settings -By choosing “New” from the dropdown for Settings you will be able to setup a new autodiscover job. The settings for the fields are as follows: +Select **New** from the **Settings** dropdown menu to set up a new autodiscovery job. The settings for the fields are as follows: | Field | Description | |-----------------|-------------------------------------------------------------------------------------------------| -| Settings | Select Pre-Configured Jobs from this dropdown | -| Name | Your chosen name for the autodiscovery job | -| Credentials | Choose one credentials for the discovery that were setup in the Settings tab | -| Device Name | Choose from one of the options to set the device name. See below for details | -| Ignore | You can choose to ignore OS name, UUID, Serial Number, Domain Suffix, IPv6 address, and/or Virtual Subtype | -| Options | You can choose to give the host name precedence, Discover Services, and if you have the add-ons, discover software and/or application inventory | -| Device Category | Choose from Device Categories you’ve configured within Device42. Selecting ‘Override’ will replace existing categories with the current selection. | -| Service Level | These values are pulled from Device42 and allow you to set the Service Level on the discovered devices. | -| Customer | These values are pulled from Device42 and allow you to associate discovered servers with the selected Customer. | -| VRF Group | These values are pulled from Device42 and allow you to assign the discovered servers to the selected VRF Group. | -| Discover by | Here you can choose CIDR Blocks, Host Names, IP Ranges, or Domain Servers to perform the autodiscovery against | -| Criteria | When Using Host Name or CIDR Blocks to auto-discover, you can enter the host names or CIDR blocks in comma-separated list form | -| IP Range | When using IP address autodiscovery, you can enter a single IP address or an address range in this section | -| Exclusions | If you would like to ignore IPs in a range, you can enter them here | - - -For Windows Autodiscovery by Domain Server, if you would like you can use a custom filter by entering an LDAP query to filter the results, excluding discovery of certain non-matching devices. +| **Settings** | Select **Pre-Configured Jobs** from this dropdown | +| **Name** | Your chosen name for the autodiscovery job | +| **Credentials** | Choose the credentials for the discovery that was set in the Settings tab | +| **Device Name** | Choose from one of the options to set the device name. See [Device Naming Options](#device-naming-options) for details | +| **Ignore** | You can choose to ignore OS name, UUID, Serial Number, Domain Suffix, IPv6 address, and/or Virtual Subtype | +| **Options** | You can choose to give the hostname precedence, Discover Services, and if you have the add-ons, discover software and/or application inventory | +| **Device Category** | Choose from Device Categories you’ve configured within Device42. Selecting **Override** will replace existing categories with the current selection. | +| **Service Level** | These values are pulled from Device42 and allow you to set the Service Level on the discovered devices. | +| **Customer** | These values are pulled from Device42 and allow you to associate discovered servers with the selected Customer. | +| **VRF Group** | These values are pulled from Device42 and allow you to assign the discovered servers to the selected VRF Group. | +| **Discover by** | Here you can choose CIDR Blocks, Host Names, IP Ranges, or Domain Servers to perform the autodiscovery against | +| **Criteria** | When Using Host Name or CIDR Blocks to auto-discover, you can enter the host names or CIDR blocks in comma-separated list form | +| **IP Range** | When using IP address autodiscovery, you can enter a single IP address or an address range in this section | +| **Exclusions** | If you would like to ignore IPs in a range, you can enter them here | + + +For Windows autodiscovery by domain server, you can use a custom filter by entering an LDAP query to filter the results, excluding discovery of certain non-matching devices. For example: @@ -125,69 +119,67 @@ For example: (&(objectCategory=computer)(dNSHostName=d42sus.pvt)) ``` -…will search the domain server for all computers with dns hostname - d42sus.pvt and autodiscover the matches. +This query will search the domain server for all computers with the DNS hostname, `d42sus.pvt`, and autodiscover the matches. -#### Run Status +### Run Status This is where you will see information about the last run status of the autodiscovery job. * * * -### Device Naming Options +## Device Naming Options -The Device42 autodiscovery tool can add or update the Device Name of any targets with the hostname format of your choosing. Device42 can combine the discovered Hostname with the Domain Name \[Option: ‘Hostname plus Domain Name’\]. You can also add the name as discovered (hostname) as an alias, rather than replacing an existing device’s name by choosing the option ‘Hostname and add Hostname plus Domain Name as Alias’. This option adds devices with the hostname as discovered as the device name, and the FQDN as the alias. Full details are below. +The Device42 autodiscovery tool can add or update the Device Name of any targets with the hostname format of your choosing. Device42 can combine the discovered Hostname with the Domain Name (Option: **Hostname plus Domain Name**). You can also add the name as discovered (hostname) as an alias, rather than replacing an existing device’s name by choosing the option **Hostname and add Hostname plus Domain Name as Alias**. This option adds devices with the hostname as discovered as the device name, and the FQDN as the alias. Full details are below. -From the Discovery tab, set your desired options, and choose the desired “Device Name” option from the dropdown. +From the **Discovery** tab, set your desired options, and choose the desired **Device Name** option from the dropdown. ![Device Naming Options](/assets/images/auto-discovery-tool-007.png) - Hostname as discovered -- Hostname plus domain name as discovered. If the domain name already exists in the hostname, it will not be added again. You may need to set “Ignore Domain Name” for the best functionality. +- Hostname plus domain name as discovered. If the domain name already exists in the hostname, it will not be added again. You may need to set **Ignore Domain Name** for the best functionality. - Hostname and add Hostname plus Domain name as alias. This is the default and recommended setting. - Hostname plus Domain name and add Hostname as alias. -In order to set the Device Name to the FQDN of the device, make sure you select an option that includes “Hostname plus Domain Name”.l +In order to set the Device Name to the FQDN of the device, make sure you select an option that includes **Hostname plus Domain Name**. * * * -### Information +## The Information Tab -#### Recent Messages +### Recent Messages -In the Information section, you have the ability to see Recent Messages which will allow you to follow the progress of your autodiscovery jobs. +In the **Information** section, you can see **Recent Messages**, which will allow you to follow the progress of your autodiscovery jobs. -#### Search Logs +### Search Logs The Search Logs section will allow you to enter search criteria to check the log files if you have problems with any of the autodiscovery jobs. -#### Diagnostic Settings +### Diagnostic Settings ![Diagnostic Settings](/assets/images/autodiscovery-05.png) -If you have trouble with autodiscovery using the application, we now have a section that will allow you to generate a log bundle to send to the Device42 team for diagnosis. This section allows you to set the location of the logs, select which logs to keep, and generate a bundle. +If you have trouble with autodiscovery using the application, you can use the new **Diagnostic Settings** section to generate a log bundle to send to the Device42 team for diagnosis. This section allows you to set the location of the logs, select which logs to keep, and generate a bundle. -#### Summary +### Summary -The Summary section displays a summary list of results of recent discovery attempts against a list of discovered IPs, including a date and timestamp. Looking at the summary is a quick way to determine if discovery against a specific IP succeeded or failed, and if failed, if the failure was possibly due to the instance residing on the IP being unreachable \[‘TCP Ping’\], or maybe because of authentication errors \[‘Authenticated’\]. A value of ‘True’ in the ‘Sent to D42’ column means that CI data in the Device42 CMDB was updated for that particular line’s instance. +The **Summary** section displays a summary list of the results of recent discovery attempts against a list of discovered IPs, including a date and timestamp. Looking at the summary is a quick way to determine whether discovery against a specific IP succeeded or failed, and if it failed, whether the failure occurred because the instance residing on the IP was unreachable \[‘TCP Ping’\] or because there were authentication errors \[‘Authenticated’\]. A value of ‘True’ in the ‘Sent to D42’ column means that CI data in the Device42 CMDB was updated for the instance in that particular line. * * * -### Tasks (Task Schedules) +## The Tasks Tab ![Tasks](/assets/images/autodiscovery-06.png) -In the tasks section, you can set as many different autodiscovery schedules as needed to cover your environment in the Schedules section. You can choose which days of the week, and whether you want to run the job at a specific time, or every X hours, as well as which discoveries to run. +In the **Tasks Schedules** section, you can set as many different autodiscovery schedules as needed to cover your environment in the Schedules section. You can choose which days of the week, and whether you want to run the job at a specific time, or every X hours, as well as which discoveries to run. In the Status section, you will see the last status of each of your autodiscovery jobs. -  - -### General Considerations +## General Considerations Here are some limitations and considerations: -- If you have populated Device42 \[CSV imports, spreadsheets, manual entry, etc.\] with devices before your first run of this tool, please make sure to run this on a few devices first to make sure the naming convention used by you and the one discovered by the tool are compatible. (For example: you added nh-linux01 as a device. Then, autodiscovery finds the hostname nh-linux01.example.com and adds it as a new device because the names don’t match. To fix this, you can check the checkbox above to use only hostname) -- It is best to use the auto-discovery client after you have run network autodiscovery and/or defined the subnets your network IPs reside on. -- Floating IPs that belong to a cluster logically but are found on a device during autodiscovery will be assigned to that device, and _not_ the cluster resource. +- If you have populated Device42 (CSV imports, spreadsheets, manual entry, etc.) with devices before your first run of this tool, please make sure to run the tool on a few devices first to ensure the naming convention you use is compatible with the naming convention discovered by the tool. For example, if you added `nh-linux01` as a device and autodiscovery found the hostname `nh-linux01.example.com`, autodiscovery would add it as a new device because the names didn’t match. To fix incompatible naming conventions, you can check the checkbox to use only the hostname. +- It is best to use the autodiscovery client after you have run network autodiscovery and/or defined the subnets where your network IPs reside. +- Floating IPs that logically belong to a cluster but are found on a device during autodiscovery will be assigned to that device, and **not** the cluster resource. - You can run the .NET Discovery tool from any (and multiple) network segments. Communication from the autodiscovery client back to the main Device42 instance requires access via port TCP/443 (HTTPS) to be allowed on your network. -- Please be sure to use an Administrator account. If you use the “Local System account”, discovery will not work correctly for other machines in the network. +- Please be sure to use an Administrator account. If you use the **Local System account**, discovery will not work correctly for other machines in the network. diff --git a/docs/auto-discovery/sccm-discovery.mdx b/docs/auto-discovery/sccm-discovery.mdx index 687ee38a..b487f6e2 100644 --- a/docs/auto-discovery/sccm-discovery.mdx +++ b/docs/auto-discovery/sccm-discovery.mdx @@ -8,9 +8,9 @@ import useBaseUrl from '@docusaurus/useBaseUrl'; # SCCM Discovery -As of 18.11.00, SCCM Discovery is integrated into our main discovery jobs. Microsoft SCCM (System Center Configuration Manager or MECM, Microsoft Endpoint Configuration Manager), is a comprehensive management platform to manage and deploy software, applications, updates, and operating systems in an enterprise environment. SCCM provides administrators with a centralized and unified solution to efficiently manage a large number of devices, both physical and virtual, running various versions of Windows, macOS, Linux, etc. +As of 18.11.00, SCCM Discovery is integrated into our main discovery jobs. Microsoft System Center Configuration Manager (SCCM) or Microsoft Endpoint Configuration Manager (MECM), is a comprehensive management platform for managing and deploying software, applications, updates, and operating systems in an enterprise environment. SCCM offers administrators a centralized, unified solution for efficiently managing a wide range of physical and virtual devices running various versions of Windows, macOS, Linux, and other operating systems -If you are already using SCCM in your environment, the Device42 SCCM integration can automatically sync the hardware and software inventory (CI) data to Device42. SCCM discovery can discover devices, OS, CPU, memory, network, and software from SCCM. +If you already use SCCM in your environment, the Device42 SCCM integration can automatically sync the hardware and software inventory (Configuration Item) data to Device42. SCCM discovery can discover devices, OS, CPU, memory, network, and software from SCCM. SCCM Discovery can be configured using either WinRM, WMI (Requires a WDS and read only access to the SMS namespace), or direct database discovery. @@ -69,19 +69,19 @@ For discovery to return detailed information, you will require read permissions
    -
  • INFORMATION_SCHEMA.TABLES
    • -
  • v_GS_COMPUTER_SYSTEM
    • -
  • v_GS_X86_PC_MEMORY
    • -
  • v_GS_Add_Remove_Programs
    • -
  • v_R_System
    • +
  • `INFORMATION_SCHEMA.TABLES`
    • +
  • `v_GS_COMPUTER_SYSTEM`
    • +
  • `v_GS_X86_PC_MEMORY`
    • +
  • `v_GS_Add_Remove_Programs`
    • +
  • `v_R_System`
    -
  • v_GS_PC_BIOS
    • -
  • v_GS_PROCESSOR
    • -
  • v_GS_NETWORK_ADAPTER_CONFIGURATION
    • -
  • v_GS_Add_Remove_Programs_64
    • +
  • `v_GS_PC_BIOS`
    • +
  • `v_GS_PROCESSOR`
    • +
  • `v_GS_NETWORK_ADAPTER_CONFIGURATION`
    • +
  • `v_GS_Add_Remove_Programs_64`
diff --git a/docs/auto-discovery/virtual-machine-auto-discovery.md b/docs/auto-discovery/virtual-machine-auto-discovery.md index 3d8b8017..ed817c4c 100644 --- a/docs/auto-discovery/virtual-machine-auto-discovery.md +++ b/docs/auto-discovery/virtual-machine-auto-discovery.md @@ -5,7 +5,7 @@ sidebar_position: 36 VMWare platforms e.g. ESX and ESXi, Citrix XenServer, HyperV, oVirt, Redhat, KVM/libvirt, OpenVZ, AIX HMC,  Nutanix Prism, Nutanix Prism Central, Docker, and LXC virtualization platforms can all be discovered directly from the Device42 UI. -While configuring the job, you may elect to have your primary Device42 appliance directly perform the discovery, or you may designate a [remote collector](remote-collector-rc.md) to run each task. +While configuring the job, you may elect to have your primary Device42 appliance directly perform the discovery, or you may designate a [remote collector](remote-collector-rc.mdx) to run each task. ## Setting up VMware/Citrix Xenserver/oVirt/KVM/LXC autodiscovery diff --git a/docs/getstarted/getting-started-with-auto-discovery.mdx b/docs/getstarted/getting-started-with-auto-discovery.mdx index 0aceae1a..05bc4c6b 100644 --- a/docs/getstarted/getting-started-with-auto-discovery.mdx +++ b/docs/getstarted/getting-started-with-auto-discovery.mdx @@ -52,7 +52,7 @@ If subnets have been pre-defined, all discovered IP addresses will be placed in ### Set Up WDS (Windows Discovery Service) -Now is a good time to set up a [Remote Collector](auto-discovery/remote-collector-rc.md), as RCs are dedicated to discovery and can handle larger network ranges than your Main Appliance (MA). +Now is a good time to set up a [Remote Collector](auto-discovery/remote-collector-rc.mdx), as RCs are dedicated to discovery and can handle larger network ranges than your Main Appliance (MA). If you’ll be discovering any Microsoft Windows OS-based servers or guests, go ahead and set up an instance of WDS. Note that your WDS instance can be connected to either your Main Appliance OR to a Remote Collector. If you do have an RC set up, it’s recommended to connect to WDS rather than connecting it to your MA. diff --git a/docs/infrastructure-management/power-and-environmental-monitoring/getting-started-with-power-and-environmental-monitoring.md b/docs/infrastructure-management/power-and-environmental-monitoring/getting-started-with-power-and-environmental-monitoring.md index 59a480a5..008d66ce 100644 --- a/docs/infrastructure-management/power-and-environmental-monitoring/getting-started-with-power-and-environmental-monitoring.md +++ b/docs/infrastructure-management/power-and-environmental-monitoring/getting-started-with-power-and-environmental-monitoring.md @@ -33,7 +33,7 @@ When sensors are discovered, they are created with Asset records in Device42. If ## Legacy documentation - Standalone Power Appliance, Depreciated 2017 -**Note to Power Monitoring / Control Users: The Standalone Power Appliance is being depreciated, and all related functionality is now available in Remote Collectors (RC's). Please utilize RC's for power / environmental monitoring or control going forward. See the [Remote Collector page](auto-discovery/remote-collector-rc.md) for setup details and for information on obtaining a Remote Collector going forward!** +**Note to Power Monitoring / Control Users: The Standalone Power Appliance is being depreciated, and all related functionality is now available in Remote Collectors (RC's). Please utilize RC's for power / environmental monitoring or control going forward. See the [Remote Collector page](auto-discovery/remote-collector-rc.mdx) for setup details and for information on obtaining a Remote Collector going forward!** The actual monitoring occurs in a separate virtual appliance from the main Device42 appliance. Please note that you can optionally monitor power using Device42 Remote Collectors from v14.0.0 forward, as well as the dedicated power appliance. This is done for three reasons: @@ -43,7 +43,7 @@ The actual monitoring occurs in a separate virtual appliance from the main Devic ### Installation -The installation process for one or more monitoring appliances is similar to installation of the Device42 main appliance. If you would like to set up power monitoring using a Remote Collector (RC), see the [instructions for setting up an RC](auto-discovery/remote-collector-rc.md). +The installation process for one or more monitoring appliances is similar to installation of the Device42 main appliance. If you would like to set up power monitoring using a Remote Collector (RC), see the [instructions for setting up an RC](auto-discovery/remote-collector-rc.mdx). Refer to the appropriate link(s) below for installation on your selected virtualization platform: \- [VMWare Player](getstarted/installation/installation-vmware-player.mdx) diff --git a/docs/infrastructure-management/power-and-environmental-monitoring/power-monitoring-and-control.md b/docs/infrastructure-management/power-and-environmental-monitoring/power-monitoring-and-control.md index 2fd2e215..ec706c9c 100644 --- a/docs/infrastructure-management/power-and-environmental-monitoring/power-monitoring-and-control.md +++ b/docs/infrastructure-management/power-and-environmental-monitoring/power-monitoring-and-control.md @@ -3,7 +3,7 @@ title: "Power Monitoring" sidebar_position: 4 --- -This section describes Device42's power monitoring capabilities. If you are just getting started, you'll want to first set up one or more [Remote collectors (RCs)](auto-discovery/remote-collector-rc.md). +This section describes Device42's power monitoring capabilities. If you are just getting started, you'll want to first set up one or more [Remote collectors (RCs)](auto-discovery/remote-collector-rc.mdx). ## Power Heatmaps diff --git a/docs/infrastructure-management/power-and-environmental-monitoring/power-rc-setup-job-migration.md b/docs/infrastructure-management/power-and-environmental-monitoring/power-rc-setup-job-migration.md index 2eb5d65f..b3aa64f3 100644 --- a/docs/infrastructure-management/power-and-environmental-monitoring/power-rc-setup-job-migration.md +++ b/docs/infrastructure-management/power-and-environmental-monitoring/power-rc-setup-job-migration.md @@ -7,7 +7,7 @@ Converting existing power autodiscovery jobs to the new PowerRC SNMP autodiscove ### Power (RC) Setup -**First, follow the instructions to setup a Remote Collector (RC) here:** - [discovery/remote-collector-rc.md](auto-discovery/remote-collector-rc.md) +**First, follow the instructions to setup a Remote Collector (RC) here:** - [discovery/remote-collector-rc.md](auto-discovery/remote-collector-rc.mdx) ### Migrating Existing Power Appliance Jobs to Power RC diff --git a/static/assets/images/cloud-auto-discovery/cloud-discovery-type-dark.png b/static/assets/images/cloud-auto-discovery/cloud-discovery-type-dark.png new file mode 100644 index 00000000..b9b7deac Binary files /dev/null and b/static/assets/images/cloud-auto-discovery/cloud-discovery-type-dark.png differ diff --git a/static/assets/images/cloud-auto-discovery/cloud-discovery-type-light.png b/static/assets/images/cloud-auto-discovery/cloud-discovery-type-light.png new file mode 100644 index 00000000..f4e6cdce Binary files /dev/null and b/static/assets/images/cloud-auto-discovery/cloud-discovery-type-light.png differ diff --git a/static/assets/images/jamf-autodiscovery/customer-option-dark.png b/static/assets/images/jamf-autodiscovery/customer-option-dark.png new file mode 100644 index 00000000..59bdb914 Binary files /dev/null and b/static/assets/images/jamf-autodiscovery/customer-option-dark.png differ diff --git a/static/assets/images/jamf-autodiscovery/customer-option-light.png b/static/assets/images/jamf-autodiscovery/customer-option-light.png new file mode 100644 index 00000000..8a238cd8 Binary files /dev/null and b/static/assets/images/jamf-autodiscovery/customer-option-light.png differ diff --git a/static/assets/images/jamf-autodiscovery/jamf-run-now-dark.png b/static/assets/images/jamf-autodiscovery/jamf-run-now-dark.png new file mode 100644 index 00000000..85a39cc7 Binary files /dev/null and b/static/assets/images/jamf-autodiscovery/jamf-run-now-dark.png differ diff --git a/static/assets/images/jamf-autodiscovery/jamf-run-now-light.png b/static/assets/images/jamf-autodiscovery/jamf-run-now-light.png new file mode 100644 index 00000000..a58a42dc Binary files /dev/null and b/static/assets/images/jamf-autodiscovery/jamf-run-now-light.png differ diff --git a/static/assets/images/jamf-autodiscovery/jamf-schedule-dark.png b/static/assets/images/jamf-autodiscovery/jamf-schedule-dark.png new file mode 100644 index 00000000..18b8aa35 Binary files /dev/null and b/static/assets/images/jamf-autodiscovery/jamf-schedule-dark.png differ diff --git a/static/assets/images/jamf-autodiscovery/jamf-schedule-light.png b/static/assets/images/jamf-autodiscovery/jamf-schedule-light.png new file mode 100644 index 00000000..976fe658 Binary files /dev/null and b/static/assets/images/jamf-autodiscovery/jamf-schedule-light.png differ diff --git a/static/assets/images/jamf-autodiscovery/new-job-dark.png b/static/assets/images/jamf-autodiscovery/new-job-dark.png new file mode 100644 index 00000000..f1d97114 Binary files /dev/null and b/static/assets/images/jamf-autodiscovery/new-job-dark.png differ diff --git a/static/assets/images/jamf-autodiscovery/new-job-light.png b/static/assets/images/jamf-autodiscovery/new-job-light.png new file mode 100644 index 00000000..58911f98 Binary files /dev/null and b/static/assets/images/jamf-autodiscovery/new-job-light.png differ diff --git a/static/assets/images/other-cloud-autodiscovery/autodiscovery-types-dark.png b/static/assets/images/other-cloud-autodiscovery/autodiscovery-types-dark.png deleted file mode 100644 index fc162745..00000000 Binary files a/static/assets/images/other-cloud-autodiscovery/autodiscovery-types-dark.png and /dev/null differ diff --git a/static/assets/images/other-cloud-autodiscovery/autodiscovery-types-light.png b/static/assets/images/other-cloud-autodiscovery/autodiscovery-types-light.png deleted file mode 100644 index 14580bcb..00000000 Binary files a/static/assets/images/other-cloud-autodiscovery/autodiscovery-types-light.png and /dev/null differ diff --git a/static/assets/images/other-cloud-autodiscovery/cloud-discovery-type-dark.png b/static/assets/images/other-cloud-autodiscovery/cloud-discovery-type-dark.png new file mode 100644 index 00000000..b9b7deac Binary files /dev/null and b/static/assets/images/other-cloud-autodiscovery/cloud-discovery-type-dark.png differ diff --git a/static/assets/images/other-cloud-autodiscovery/cloud-discovery-type-light.png b/static/assets/images/other-cloud-autodiscovery/cloud-discovery-type-light.png new file mode 100644 index 00000000..f4e6cdce Binary files /dev/null and b/static/assets/images/other-cloud-autodiscovery/cloud-discovery-type-light.png differ diff --git a/static/assets/images/remote-collector-rc/actions-menu-dark.png b/static/assets/images/remote-collector-rc/actions-menu-dark.png new file mode 100644 index 00000000..fc5a4ae5 Binary files /dev/null and b/static/assets/images/remote-collector-rc/actions-menu-dark.png differ diff --git a/static/assets/images/remote-collector-rc/actions-menu-light.png b/static/assets/images/remote-collector-rc/actions-menu-light.png new file mode 100644 index 00000000..2350887e Binary files /dev/null and b/static/assets/images/remote-collector-rc/actions-menu-light.png differ diff --git a/static/assets/images/remote-collector-rc/logging-level-dark.png b/static/assets/images/remote-collector-rc/logging-level-dark.png new file mode 100644 index 00000000..21e0e4e9 Binary files /dev/null and b/static/assets/images/remote-collector-rc/logging-level-dark.png differ diff --git a/static/assets/images/remote-collector-rc/logging-level-light.png b/static/assets/images/remote-collector-rc/logging-level-light.png new file mode 100644 index 00000000..cdf76780 Binary files /dev/null and b/static/assets/images/remote-collector-rc/logging-level-light.png differ diff --git a/static/assets/images/remote-collector-rc/menu-otp-dark.png b/static/assets/images/remote-collector-rc/menu-otp-dark.png new file mode 100644 index 00000000..8e27321d Binary files /dev/null and b/static/assets/images/remote-collector-rc/menu-otp-dark.png differ diff --git a/static/assets/images/remote-collector-rc/menu-otp-light.png b/static/assets/images/remote-collector-rc/menu-otp-light.png new file mode 100644 index 00000000..96234fef Binary files /dev/null and b/static/assets/images/remote-collector-rc/menu-otp-light.png differ