Scanning

This article describes scanning in Movere. Movere can scan, discover, and capture your on-premises environment, and devices in other public clouds such as AWS and GCP.

Movere scans devices independent of the platform (windows or linux) or hosting provider (on-premises environment, private cloud or public cloud). Movere doesn't require a VMware or a hypervisor environment. Movere can reach any device if it is online.

What can I scan?

Here's what you can scan in Movere.

Scan	Details
Windows devices	Scan Windows devices with Windows Server operating systems, Windows client operating systems from Active Directory domains, or by device FQDN, DNS, or IP address. Devices can be domain-joined or not connected to the domain such as devices in a workgroup. You can run scans in the Movere Console, or from the command line. You run actual resource consumption scanning to capture device consumption data from Windows Server devices, to show system performance over time.
Linux devices	Scan supported Linux devices from Active Directory, from specific subnets, or using DNS or IP addresses. You can run scans in the Movere Console, or from the command line. You can collect actual resource consumption data from Linux devices.
Active Directory	Scan Active Directory objects (computers, users, and trusts). You can scan a single domain, or multiple domains for a forest-wide discovery.
vCenter appliances	Scan VMWare vCenter Server Appliances remotely from the Movere console. Appliances are preconfigured Linux VMs, optimized for vCenter Server. VMWare vCenter Server Appliances can also be scanned as Linux device.
Windows vCenter Server	Scan the SQL instance running the vCenter Server database.
SQL Server	Collect SQL Server data from Windows and Linux devices. - If Movere detects a SQL engine on a device, but it can't connect to SQL, then it collects basic configuration data. - If Movere has access permissions to scan SQL data, it can collect additional information about SQL itself and other Microsoft products that leverage SQL as underlying database such as Sharepoint, System Center, Exchange. - If actual resource consumption scanning is enabled for SQL, it collects performance and database connection information. Learn more about SQL data collected by Movere.
Microsoft 365	Scan subscription data. Gather information about Microsoft 365 users, and the subscriptions assigned to them.

Scanning devices in public clouds

When you scan devices in public clouds such as AWS and GCP you use the same requirements, processes, and procedures as any other device scanning. There aren't any special instructions. The device running the Movere console should be connected to the relevant cloud environment for scanning to work. We recommend that you scan from within the cloud environment, but you don't have to.

What data is scanned?

In addition to scanning Windows and Linux devices, both Physical or Virtual, Movere gathers data from Active Directory, VMware vCenter, Exchange Server, SQL Server, SharePoint, Dynamics CRM, Microsoft 365, System Center Configuration Manager, System Center Virtual Machine Manager, System Center Operations Manager, System Center Data Protection Manager, Lync Server, Hyper-V, Altiris, LANDesk, LanSweeper, and BigFix.

Inventory scans

Movere supports inventory scans, and actual resource consumption scans.

An inventory scans captures point-in-time configuration data from devices and apps. Each time inventory data is collected, it reports the latest available information, and supersedes anything that was previously collected. For example:

• An inventory scan captures information that a device is running Windows Server 2016 with 4 GB of RAM.
• After the scan, you increase the RAM to 8 GB, and run an inventory scan.
• The scan now reports 8 GB of RAM, but doesn't report that the system was assigned additional RAM since the last scan.
• You can do a manual analysis to discover this, but Movere doesn't report it.

Inventory scan bots

An inventory scan is run using bots for Windows and Linux and can also be performed remotely for Windows only. Movere inventory bots are small (around 2 MB in size), and produce a data file or payloads that is usually less than 10 KB. Bots aren't persistent. Since they're small, they can be easily deployed, run, and removed. No persistent agent is needed on devices you want to scan.

Inventory scan process

An inventory scan works as follows:

1. The inventory bots are copied to the device you want to scan.
2. The bot runs once, and produces an output file.
3. The bot then stops and deletes itself.
4. Movere bots can push the payloads back to the Movere Console or directly to the Cloud.
5. Movere also supports pull mechanism (for Windows only) to fetch the payloads from the target devices without support for TLS 1.2.

You typically schedule an inventory data scan to run every few days or weeks.

Actual resource consumption scans

Actual resource consumption scans gather system performance information over a defined period. Unlike an inventory scan, it gathers consumption data (processor, memory, disk usage) that's constantly changing.

Actual resource consumption data is particularly useful during migration planning. It can be used to accurately calculate cloud sizing, to ensure that devices maintain or improve performance, after migration.

Resource consumption scan bots

In Windows operating system, Actual resource consumption bots, by default, runs as an installed service. In Linux operating system, Actual resource consumption bots runs as a process. If the linux machine restarts or reboots, the user needs to restart the scanning again. Unlike inventory bots, Actual resource consumption bots need to remain running, to capture consumption data over time.

• Arc2: The Movere actual resource consumption binary that's compatible with .NET 3.5 framework and with x86.
• Arc4: The Movere actual resource consumption binary that's compatible with .NET 4.0 framework, or higher and with x64.

Before scanning, bots perform pre-scan checks, including process enumeration speed, and process-level performance counter access. These checks:

• Protect against CPU spikes, or performance counter permission issues.
• When encountering a slow system or a permission denial, the bots capture macro-level performance metrics, and skip details such as process level CPU, RAM, path, and version. This way, Movere can assess consumption, without negatively impacting system performance.

Collected data

Actual resource consumption scans collects data from following sources.

• Windows systems:
  • Windows process: Windows PerfMon, Windows Common Information Model (CIM)
  • Disk performance: Windows PerfMon
  • Network throughput: Windows PerfMon
  • Netstat: Windows IP Helper Library
  • Events: .NET connector to Windows Events
  • SQL Server: Movere SQL queries
• Linux systems:
  • Bash shell command output (for example ps, df, netstat)
  • Direct query of system virtual files, for example /proc/diskstats

To track usage changes, and accurately calculate peak workloads, data is usually captured on a frequent basis. For example, every five, 10, or 15 minutes, over multiple days or weeks.

Resource consumption scan process

An actual resource consumption scan works as follows:

1. You specify how often data should be collected (frequency), and for how long (duration).

   • The frequency of an actual resource consumption scan denotes how often an ARCBeat is generated on each target device (every 5, 10, 15, 30, or 60 minutes).
   • ARCBeat is the time that elapses between two resource consumption data collection points. The default is five minutes, but you can modify this value in the Console.
   • For example, if you select five minutes, that's up to 288 possible ARCBeats in a day. (12 ARCbeats per hour x 24 hours).
   • The duration denotes how long the scan runs on each target device (one, three, seven, 30, or 90 days). The default duration is 7 days.
   • You can optionally collect SQL data during the scan. By default it's not collected.

2. The actual resource consumption bots (Arc2, Arc4), and collection settings, are sent to the device you're monitoring.

3. The bot captures usage data in line with the specified settings.

4. If you enable automatic upload to the cloud directly from the target device, Movere makes three attempts to upload the data to the cloud. If upload fails, the following occurs:

   1. The bot makes three attempts (one every 30 seconds) to transfer the payload to the Movere Console device.
   2. If transfer to the Console fails, then the bot saves the payload locally. If the transfer/upload suceeds then the payload is deleted from the target device.
   3. When the next ARCbeat occurs and the new payload is generated, the bot again tries to establish a connection with the cloud or Console to upload the remaining payloads.
   4. The bot continues to run on the target device for the duration of the scan, and uploads or transfers the saved payloads as soon as the connection is established.

5. After a successful upload, the bot waits for the next data collection, in accordance with the frequency and duration settings. The bot remains in place for the specified duration.

6. After the scan duration ends, the bot terminates and deletes itself.

Scans and rescans

Movere provides the following options for running a scan:

• First scan: Run the scan immediately. You initiate the scan at the end of the scanning wizard, in the Movere Console. This is intended for bulk operation such as scan every device in Active Directory, M365 users.
• Rescan: The rescan option is useful to target devices that haven't been scanned in the first scan. This is a preferred scanning method if you have not reached the desired inventory coverage after the first scan. For example:
  • If you run a first scan that targets only on Active Directory, and now you want to use the results to target active Windows devices or active linux devices.
  • To target non-domain joined/workgroup devices
  • To target devices that can't be captured during a prior scan such as devices where scanning was denied due to inadequate permission, users should use rescan to target the device with the correct set of permissions.
  • To target devices you've already scanned, in order to update inventory data, or capture environment changes on the devices.

Rescan types

To rescan devices, you can use one of the following scanning sources of data.

Method	Details
Rescan based upon active list of devices	You can select: - Active Windows servers/workstations that haven't been inventoried at all, or during the last 31 days. This can be run only after a successful scan of Active Directory. - Active Linux devices that haven't been inventoried at all, or during the last 31 days. This option scans for devices regardless of device state. In large domain, or domains with many stale objects, this option can increase scanning time.
Rescan based on a rescan file	The rescan file (.CSV) can be downloaded from the Movere portal, or you can manually create a custom (.CSV) file. For Linux devices, you can't select to use a rescan file in the Console. You can use a rescan file for Linux devices from the command prompt.

Scanning outside the console

You can deliver bots to target devices, and run scans, outside the console. Although we recommend using the Movere Console to deliver bots, Movere does support placement of the bots either manually, or using third-party software. Learn more

Scanning methods

You can select among the following scanning methods when you set up a scan.

Method	Process
Scan as a service (recommended)	Movere evaluates the .NET version running on the targeted device, and attempts to scan three times: - First try: Movere copies the bot to the device with the user account provided in Manage Credentials. The bot runs as Local Service. The scan runs using the NT Authority\System account on the device. - Second try: If the first try doesn't work, Movere copies the bot with the user account provided, and runs the bot as a local process. - Third try: If the second try doesn't work, Movere runs the scan with the user account provided, and gathers information using Remote WMI.
Scan as a process	If you don't want bots to run as Local Service, select this option to run Movere as a local process. Movere tries to scan twice: - First try: Movere copies the bot with the user account provided in Manage Credentials. The bot runs as a local process. - Second try: If the first try doesn't work, Movere doesn't copy the bot. The scan runs with the user account provided, and information is gathered using Remote WMI.
Scan remotely using WMI	This is an older technology we don't recommend using, unless: - You can't deploy bots. - .NET isn't supported for target devices (For example, Windows 2000, Windows 2003, Windows XP). With this method no bot is copied. The scan runs with the user account provided, and information is gathered using Remote WMI. WMI collects inventory data only, with no actual resource consumption scanning. Movere scans across the network. Scan speed depends on network bandwidth, and the condition of the devices being scanned. If a .NET scan typically completes within 30 seconds, a WMI scan can take three to five minutes for the same scan.

.NET scanning

By default, Movere uses the .NET framework to scan each Windows device locally, providing two key benefits:

• Minimize network traffic. Movere creates a temporary local service to capture primary Windows data, and secondary data such as SQL Server and Exchange. By scanning devices locally, communication between the Movere Console and each targeted device is limited to delivery of the Movere scanning engine (< 5MB), and the return of the encrypted output file (typically < 10 KB for inventory scans and 5 KB for actual resource consumption scans).
• Minimize memory use. The Movere scanning engine only uses resources that are available, and doesn't deprioritize any existing running application.

.NET scanning works as follows:

1. Movere connects to the device, using the credentials you specify in the Movere Console.

   • After accessing the device, scanning is performed using the Local System account when running as a service, or using the account provided in the console when running as a process.
   • If the targeted device has SQL Server installed, Movere accesses SQL using the same credentials. If they don't work, Movere tries to access SQL Server using other credentials added in the Movere Console, in the order in which they're added.

2. The inventory and actual resource consumption bots, as well as the FrameworkVerifier and token file, are delivered to Windows target devices.

   • The bots and files are delivered via ports 139 and 445.
   • Successful delivery returns Launching bot and Service success messages in the Console, via a random port number selected by Windows.
   • When the FrameworkVerifier starts, the endpoint switches to port 443. If it can reach the Console over 443, a Local scan started message appears in the Console.
   • These messages confirm that the bots have been successfully delivered, scanning has started, and that the targeted device can communicate with the Movere Console.

3. When a scan starts, resource usage on the targeted device is checked.

   • For example, if a scan starts and the targeted device is currently using 80% CPU, Movere is limited to a maximum of ~10% of the total system resources
   • Windows uses a complex algorithm to ensure that it keeps resources available for the operating system itself.
   • If the device has more resources available, then Movere takes advantage of the additional resources. The .NET framework makes this decision, not Movere.
   • If there aren't enough resources, the following errors appear:
     • Insufficient memory to continue the execution of the program: When the target device has insufficient resources, Movere terminates itself, instead of placing the device under further strain.
     • Insufficient system resources exist to complete the requested service: If the targeted device has insufficient processing power to perform the requested tasks, Movere terminates itself.

4. Total scan time per device is considered. Movere can scan most devices within 30 seconds. So for example, if Movere is allocated 10% of the CPU, it can complete scanning in less than a minute. If it has more than 10% of the CPU, scan time is reduced even further. Total scan time is influenced the products running on a device. For example, a device with SQL Server installed takes longer to inventory than a device without SQL Server.

5. When .NET, together with the operating system, allocates resources to Movere, Movere sets the thread priority to the lowest available level.

   • If other applications need the compute cycle, they're given priority.
   • If other apps don't request CPU, then the Movere bots run with the allocated CPU resources, so that they can complete scans in the shortest possible time.

6. The bots/binaries are sent to the targeted device.

   • The inventory binaries are around 4 MB (Bot2/Bot4/FrameworkVerifier)
   • For actual resource consumption, the binaries add approximately 3.8 MB (Arc2/Arc4).

   The binaries are written to disk, by copying them to the Temp folder in the Admin$ share of the target Windows device. If The Admin$ share is not accessible then Movere will attempt to copy them to the C$ share in the Temp folder.

7. The output created by Movere is generated in memory, encrypted, and saved to disk in the same location.

8. At the end of the scan, after the output file is uploaded directly to Movere, or to the Movere Console, Movere self-deletes the bot files, leaving no trace on the scanned device. Actual resource consumption bots contain multiple safety checks, designed to gracefully exit a scan.

Determine the scan type

To determine whether Movere can scan a system locally or remotely, Movere queries the Windows Common Information Model (CIM), and the Windows registry.

• If Movere can't connect to the CIM, then no further scanning is attempted.
• If Movere can connect to the CIM but not the registry, then scanning continues, as the data Movere collects from Windows devices is primarily from the CIM.
• Whether Movere is scanning the target locally or remotely, it uses:
  • The .NET System.Management.ManagementObjectSearcher, which initializes a new instance of the ManagementObjectSearcher class, used to invoke a specific query in the specified scope (root\CIMV2).
  • The .NET System.Win32.RegistryKey, which represents a key-level node in the Windows Registry. This class offers registry encapsulation and Movere only opens it in non-writable mode (read-only), so that Movere can't change the registry.
  • Movere’s access to the registry is governed by Windows permissions, and both 32 and 64-bit connection methods are used to account for older Windows systems.
  • If the targeted endpoint is scanned remotely, then the connection is made via Windows Management Instrumentation (WMI).
  • For remote scanning Movere uses impersonation to get the correct access level, coupled with a timeout of 30 seconds to account for slow connections made via WMI. Movere uses account impersonation and requires logon type LOGON32_LOGON_INTERACTIVE for both remote and bot-based scanning.

Windows device scanning

When you set up scanning for Windows devices, you select the type of Windows devices you want to scan.

• You can run an inventory scan on both Windows Servers and Windows Workstations, and an actual resource consumption scan on Windows Servers.
• You can scan devices in specific Active Directory domains, target specific devices by FQDN or IP address, or target devices in a specific subnet.
• You can also scan devices in a workgroup, or perimeter network.

You need specific credentials for scanning Windows devices.

• The account needs Local Admin access on devices you want to scan.
• During Windows device scanning, Movere collects data from secondary sources such as SQL Server. It's important to note that Movere doesn't allow the use of accounts with Domain Admin privileges to collect this secondary data.
• Since you can't use a Domain Admin account for secondary data, instead you can create a dedicated account for Movere, and assign it the Local Admin permissions needed. Learn more.
• You have to specify at least one set of credentials before you can run a scan.
• The credentials you enter in the Movere Console are encrypted using a symmetrical key algorithm. The exact algorithm and variables used to create the key are highly confidential. This process has been reviewed independently by third parties, and isn't considered a risk, since the bots dissolve on the targeted devices, after they've completed scanning.
• Movere doesn't store credentials in plain text, and no credentials are uploaded to the cloud.

Review the permissions needed for Windows device scanning.

Linux device scanning

Movere's Linux binaries contain optimized C++, Golang code to ensure that Linux scans run as efficiently as possible. Movere utilizes built-in Linux features that are thoroughly vetted, and come packaged with most distributions to ensure a timely response and minimum usage.

Linux device scans should be run by users with secure shell (SSH) access to the Linux devices you want to inventory.

• In the Movere Console, you can specify either a username/password combination, or an SSH Private Key that permits access.
• Movere support Open SSH private key as well as RSA SSH private key. Users must inspect the first line of private key and ensure that should be a RSA header private key such as ---BEGIN RSA PRIVATE KEY--- or a OpenSSH header private key such as ---BEGIN OPENSSH PRIVATE KEY---.
• While root access isn't required, if you have virtualized Linux devices, certain data points such as the universally unique identifier (UUID) (used to link a virtual device to a physical host), won't be collected without root access.
• Movere can also run without the sudo command if the the linux account provided in Movere has basic access to linux device via SSH
• If you specify a username, use the UPN format such as user@domainname.com, and not domain\username, if the account is part of an Active Directory domain.

Scanning commands

Movere uses SSH to execute bash commands remotely. The Linux user account must be able to run these commands from the Movere Console device. Commands used by Movere are summarized in the table.

Command	Details
uname	Confirms the device name, and identifies the device architecture (32-bit or 64-bit). This determines which Movere Linux bot is used to scan the device.
pidof	Checks to see if a Movere Linux bot is already running on the device. If there is one, then it returns the bot’s process ID.
kill	Used only if the pidof command finds a Movere bot already running on the device. If a bot is running, it's terminated so that a new scan can be started. As an example, you might use this command if you ran a proof-of-concept resource consumption scan for three days, and then after one day you decided to start a 30 day scan. Instead of waiting two days for the first scan to complete, you start the second scan, terminating the first one.
which	Identifies the location of the commands Movere attempts to use. You can use this command: which uname, pidof, sudo, kill, chmod, nohup, to find the location of each command. If a location is returned for each, then the user account can run a scan.
scp	Copies the Movere files from the Console device to the target Linux device. Files are placed in the home directory of the Linux account that's specified in the Console.
nohup	Used because the Movere Linux bot runs in the background by default. If you sign out of the session, or the connection is prematurely terminated, then the process is terminated or hung up. This command keeps that from happening.
chmod	Makes the Movere Linux bot executable on the system being scanned. If you can change the bot mode to executable ‘chmod 755’, then the bot will run. If not, then the scan won't start.
sudo	This command elevates the user to admin. This isn't required. The only data point Movere might not capture if sudo isn't available is the target device’s UUID/serial number. This field isn't needed, and is only used to link VMs when the devices are cloned, and the clone is given the same FQDN and MAC address as the original. This rarely occurs.
ps	Reports a snapshot of the current processes.
mkdir	Creates a new directory.
touch	Changes a file timestamp.

Note that:

• For Linux devices, the bots are copied to the home directory of the user account running the scan.
• After the bot is executed, it uses these commands locally on the targeted device, to collect inventory and resource consumption data:
  • lsb. cat, whoami, hostname, grep, lshal, awk, dmidecode, ifconfig (usually /sbin/ifconfig), ip (usually /sbin/ip), lsblk, df, ps, dpkg-query, rpm, test, find, netstat, gpg, gpg2.
  • These commands aren't run during each scan. Some depend on the output of a previous command.

Active Directory scanning

Movere connects to Active Directory as follows:

• Movere connects using the .NET System.Net.LdapConnection, which is a low-level LDAP connector that allows for paging. This enables Movere to request large datasets, such as Active Directory Users, with very little overhead.
• For Global Catalogue queries, (for example, collecting a list of child domains in a forest), Movere uses the .NET System.DirectoryServices.Protocols.LdapDirectoryIdentifier, to connect to the Global Catalog over port 3268.
• Movere only needs to query a single domain controller per domain. It relies on Active Directory to direct it to the closest domain controller. The same logic applies when querying the Global Catalog.
• The Movere console will detect and populate the domain name of the device in which the console is running. If the device running the console is not domain joined, then no domain is populated.
• When running an Active Directory scan, Movere leverages the credentials mapped to that domain in the Movere Console.
• You can specify any domain name or workgroup name in the console using the text box on the domain tab.
• The domain is then automatically added to the domain list in the credential mapping tab.
• This enables you to enter credentials centrally from the Movere console before starting the scan.
• By default, Movere collects both device and user objects from Active Directory. Although this is the recommended approach, you can exclude user objects from a scan run from a command prompt.
  • If user data isn't collected, Movere still lists the accounts that log into each device during inventory and actual resource consumption scanning, but it won't resolve them against Active Directory.
  • The user first name, last name, email address, company, employee number/ID, country/region fields etc. are blank. since Movere won’t have this data.
    • This impacts products like SharePoint, Skype for Business, Exchange, RDS, Dynamics CRM, and Project Server from a user perspective only.
    • Movere still sees these apps, but doesn't present information about the users accessing them.
    • Other data is unaffected.
  • Excluding the collection of user data doesn't impact user data collected during the Movere registration process. This data is required for secure user access to the Movere website.

SQL Server scanning

Movere scans SQL as follows:

1. Movere confirms that a SQL engine is both present and running in order to scan it.

   • To identify SQL engines, Movere enumerates the services present on the targeted endpoint via the CIM.
   • If a SQL engine is present, but it's a passive instance, then Movere makes no attempt to connect to it.
   • Movere also makes no attempt to connect to SQL Reporting, Analysis, or Integration instances.

2. To start scanning, Movere uses the credentials assigned to a domain, in the order they are entered.

   • Movere always starts with Windows credentials, and you must enter at least one set of credentials before scanning can begin.
   • If these credentials fail, Movere attempts to connect using any other credentials assigned to the targeted domain with exception of domain admin credentials. Domain admin credentials are never transferred to the bots.
   • If all Windows based credentials fail, then Movere will use any SQL based credentials entered in the console. Please note : SQL based credentials are not linked to a particular domain and hence, all the SQL credentials (if multiple credentials are entered) will be used in the order they are entered.
   • If all credentials fail, Movere makes one last attempt to connect using the account that started the scan, which could be the credentials of the Movere user, or the local system account.

3. After a running instance of a SQL engine has been confirmed, and credentials are in place, Movere connects via TCP. To connect, Movere queries the registry to identify the port number on which each running instance is listening. Movere attempts to connect to SQL Server using the server name, via the identified port number.

   • Movere doesn't try to bypass TCP. Movere doesn't use named pipes. This is the primary reason why Movere doesn't usually connect to SQL Express instances, since networking protocols, including TCP, are disabled by default in Express Edition.
   • Movere won't attempt to connect using the device IP address, random port numbers, or using the assumption that SQL instances are using SQL port 1433.
   • The only exception to this is a SQL Server cluster. If a SQL server cluster is identified from an active node, Movere attempts to connect to SQL Server using the cluster name, and not the node name.
   • The connection to SQL Server is identical whether the device is scanned locally or remotely, and it is always done using the .NET native SQL client libraries.

4. To identify the databases on each SQL Server, Movere queries the master database, for a list of databases. A schema check is performed against this list.

   • If Movere hasn't been given access to the master database, it goes to the CIM to retrieve a list of the active databases. This provides a workaround if Movere only has access to the databases you want to scan.
   • To avoid running queries against every database, Movere performs a schema check on each database. If a match is found, a set of queries specific to that technology (and version) is run against that database.

5. To run the Movere inventory and actual resource consumption scan, the account used for scanning SQL need View Server State role, View Any Definition role and db_datareader access to SQLServer master, msdb, and any created databases.

   • If the Movere user account doesn't have access to SQL Server, then Movere can still collect basic information about SQL Server including:
     • The name and size of each database on the server that isn't in a offline state.
     • If a database isn't in an offline state, then it can be in one of several states including online, restoring, recovering, suspect, or emergency.
     • If Movere has no access to SQL Server, and is retrieving a list of databases from the Windows layer, instead of assuming each database is in an online state, Movere reports the state as Unconfirmed.

6. Movere collects data. To avoid ingesting stale data, Movere captures the last date that the data was written to the database. If it is more than 90 days old, the data collected is held as potentially stale.

Resource consumption scanning

By default, Movere doesn't collect SQL data when you enable actual resource consumption scanning. You need to specifically enable the collection of SQL data when you set up resource consumption scanning in the Movere Console. Alternatively, you can set the CollectSql value to True in the ARC2 and ARC4 configuration files.

Scanned SQL data

Movere scans the categories of SQL Server data summarized in the table.

Data	Details	Account needed
List of databases Including state, size, creation date, and clustering, mirroring and availability groups information in the master database.	Movere collects the database list by default, and doesn't need to create a specific service account.	Movere first uses the Windows credentials mapped to the domain where the SQL Server resides, followed by SQL credentials and then finally uses the NT AUTHORITY\SYSTEM account when running as a service. The desired account must be enabled for login, with the Public server role, and with permissions to connect to the database engine. All these are enabled by default. For SQL Server 2008 R2 and previous version, the NT AUTHORITY\SYSTEM was also assigned sysadmin privileges by default. This was removed in SQL Server 2012. This implies that while scanning SQL Server 2012 and above, the desired user account must specifically be granted access to SQL Server.
Performance and connection information	This includes CPU usage per min by instance, CPU usage by DB, and database connections.	Movere first uses the Windows credentials mapped to the domain where the SQL Server resides, followed by SQL credentials and then finally uses the NT AUTHORITY\SYSTEM account when running as a service. The desired account must be enabled for login, with the Public server role, and with permissions to connect to the database engine. All these are enabled by default. To collect SQL Server performance data during an actual resource consumption scan, set the option in the Movere Console.
Log shipping details (msdb db)	Log shipping configurations are stored in the msdb database.	For log shipping, the desired account must be given db_datareader access to the msdb database (unless the SQL version is old and the NT AUTHORITY\SYSTEM account has sysadmin set). If log shipping is used and Movere can't access the msdb database, then log shipping configurations aren't shown in the Movere portal.
SQL Server secondary data and drive statistics	Scans data hosted on SQL Server in support of a application such as System Center Configuration Manager, Sharepoint.	The desired account must be given db_datareader access to the secondary database (unless the SQL version is old and the NT AUTHORITY\SYSTEM account has sysadmin. This also include performance and disk statistics data that is collected at the database level. This type of scan requires sysadmin permissions. If you need this level of detail, either grant sysadmin access to the NT AUTHORITY\SYSTEM account,or to a service account that Movere can use.

Differences in views

The table summarizes the minimum access required to the database to collect various performance data with SQL actual resource consumption scan.

Performance Data	Minimum access to the database
CPU instance-level data	Master
CPU database-level data	Master
SQL disk utilization	Individual database
SQL database connections	Master
SQL database read/write data	Individual database
SQL database used v total size	Individual database

Credential mapping

Within an organization, one set of credentials is unlikely to have access to all domains and devices. When you configure a scan, Movere gives you the option to specify which credentials should be used, in which domains.

• You can use one account across all targeted domains, or map different credentials to different domains.
• Mappings between credentials and domains are provided in the Movere Console and saved in the .config file in an encrypted format.
• If the credential provided are different than the user running the console then the credential must have full control to the folder in which the Console has been installed.
• Movere doesn't currently support the use of multiple Linux credentials. Only one Linux credential can be used for Linux scans.
• SQL Server credentials don't need to be mapped to domains. These credentials are only used to connect to SQL Server instances, irrespective of the domains they are in.
• If you scan Windows devices by IP address, before scanning, Movere attempts to resolve the IP address back to an FQDN. Success depends on the network settings.
  • If it's successful, Movere uses the credentials that assigned to that domain in the Movere Console.
  • If the IP address doesn't resolve, then the credentials of the user running the scan are used. Movere doesn't cycle through the credentials list in the hope of gaining access, as this might lock out these accounts.

Scanning via a firewall/proxy

• If the target device has firewall, Movere can leverage file and print sharing, or remote administration. If either exception is permitted by your firewall, then Movere passes through it securely.
• For uploading via a firewall, Movere leverages the credentials stored in the Windows Control Panel > Internet Options > Connections > Local Area Network settings. This setting is located in the MovereService.exe.config file.
  • Movere uses the proxy on both the Movere Console device, and on target devices, as long as the settings are correct.
  • If a proxy server is blocking Movere on the Console machine from reaching the internet, the following error message appears: Error connecting to server. Exception: The remote server returned an error: (407) Proxy Authentication Required.

Next steps

Scan Windows devices.