There are two types of tenants in Movere: Customer and Partner. The tenant your user account is a member of controls what you can see and do, with the two key differences being access to data and the ability to upload data.
Members of a customer tenant can only access that tenant. Members of a partner tenant can access multiple customer tenants that they have permission to access.
While partners can access multiple customer tenants they are authorized to access, only users in a customer tenant can upload data to Movere.
Movere leverages SMS based two-factor authentication. As part of the registration process, you will be asked for a phone number that you can be reached at. Certain cell providers by default block SMS text messages from oversea numbers. If you are not receiving SMS text messages from Movere then you will need to contact your cell provider and have them white list our phone number on your account.
Our SMS text number is: +1 206 900 8003
Data presented on the Movere website can only be gathered using the Movere Console “Console”, which is unique to each customer. While any user can download the ~2MB Movere Installer, only customer tenant user(s) with a ‘Write’ claim can install the complete set of Movere binaries and security tokens required to upload data.
The Movere Installer “Installer” can be downloaded by clicking on the Console icon on the Movere website:
This will download a ~2MB executable titled ‘Movere.Installer.exe’. While the Installer can be downloaded by any user with a valid Movere login (customer or partner), the Console itself can only be installed by a customer tenant user with a ‘Write’ claim within the Movere tenant it was downloaded from:
Once downloaded, copy the Installer to the Windows device(s) you want to run the Console from.
We recommend creating a dedicated service account for Movere to use AND using that account to log into the Windows device(s) the Console will be installed on, as the permissions required to open the Console will be set automatically as part of the installation process.
IMPORTANT: This account used to run the Movere Console must be a local admin on both the device(s) the Console is installed on AND on the Windows device(s) Movere will be scanning. If utilizing the Movere credential mapper to add multiple sets of Windows credentials to be used for scanning, then make sure each set of credentials have full access to the folder housing the Console binaries.
Minimum System Requirements
Minimum system requirements for running the Console include:
- Operating System: 64-bit Windows Server 2008R2 SP1 (or above)
- .NET Framework: 4.7.2 (or above)
To check, run the following command in Command Prompt as an Administrator: reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\full" /v version
- Memory: Minimum 8 GB RAM
- Storage: Minimum 1 GB free space
If all Movere payloads are to be uploaded to the cloud via the Console device, then we recommend leveraging SSD storage.
- TLS 1.2 support. If you are running the Console on a version of Windows prior to Windows 10 or Server 2016, then TLS 1.2 may not be enabled. Please use one of the following guides on how to enable it:
- TCP Port 443 outbound external and inbound internal (refer ports section below for further details)
IMPORTANT: Only one copy of the Console can be installed and run per Windows device. The device must have TCP port 443 open, and not in use. During deployment, the Console installs a certificate that is bound to port 443. If this port is already in use, or has a certificate tied to it, Movere will not install or run. We do not recommend running the Console on a device that acts as a web (IIS) server or a similar role.
The full list of minimum Movere requirements can be found here.
URLs & IP Addresses
There are two IP addresses to white list based upon the region your Movere tenant resides in. The full list across all regions can be accessed here. While there are only two IP addresses per region, some security products can only white list URLs. Several services are required to run Movere including User Authentication, Tenant Emulation and Uploading, and if sites can only be white listed based upon URL, then all 9 (specific to each region) will need to be white listed.
Here is a quick test that can be performed to confirm connectivity to Movere. Open a browser and navigate to: https://geo.movere.io/ip. If you see an IP address, you can connect to Movere:
Some anti-virus products will block all newly installed executables by default. If applicable, the following executables should be white listed on all Windows devices:
Default installation location: c:\Windows\Temp\
The following executables only need to be white listed on the Console device(s):
To begin the installation, right click on the installer and select ‘Run as administrator’:
On the ‘Notice and Acceptance’ popup you will find links to the terms and conditions governing the use of Movere. Once these items have been reviewed and approved check the ‘I Accept’ checkbox to proceed. The ‘OK’ button will remain greyed out until the ‘I Accept’ box has been checked:
If your username and password are valid and TCP port 443 outbound is available, then you will see a ‘Logon Successful’ message after clicking on the Authenticate button (refer below):
The installation path defaults to the Documents folder in the user’s profile, but this location can be configured as required e.g. c:\Movere\Console. The user permissions required to run the Console will be set automatically on the selected destination directory. Once the installation has been completed, Movere will confirm that the certificate created during the installation process has been successfully installed:
The certificate Movere creates during the installation process includes both the fully qualified domain name of the Windows device the Movere Console is installed on, as well as ALL active IP addresses detected on the device. The IP address(es) detected will be listed in the Subject Alternative Name field. There is no longer a need to disable IP addresses before or after installing the Movere Console. The Movere bots will be able to communicate across all of them, i.e. the user will no longer be required to tell the Console which one to use:
NOTE: The IP address(es) MUST be IPv4, Movere does not currently support IPv6 addresses as Subject Alternative Names.
Opening the Console for the first time will prompt the user for a Magic Word:
This prompt will appear each time the Console is opened until at least one set of credentials (Windows, SQL, Linux, etc.) have been added to the Console via the ‘Manage Credentials’ tab. Once one or more credentials are saved, the user will be prompted for their chosen Magic Word going forward.
The Magic Word is not stored on disk nor in the cloud and therefore cannot be reset or recovered. It can be the same or unique to each copy of the Console you choose to deploy in your environment; but it must be at least 12 characters long and include the following characteristics:
- One upper case letter,
- One number; and
- One special character.
IMPORTANT: If you forget the Magic Word after saving credentials in the Console, then you will need to uninstall then reinstall the Console to regain access. You can then reenter any credentials previously added.
Credentials and Propagation
The Console will only function correctly if executed by personnel with local admin access to the Windows device(s) the Console is installed on, and the Windows device(s) to be scanned. These permissions are assigned to Domain Administrators by default, but for security purposes, Movere prohibits the propagation of credentials with Domain Admin privilege to the Movere Bots “Bots”. This means Domain Admin credentials can be used to run the Console and scan Windows devices, however they will not be sent to the Bots to collect secondary data (i.e. SQL Server). Domain Admin credentials can only be leveraged to collect data from SQL Server using impersonation. This is possible when the Bot runs as a local process using the ‘Local Scan’ scanning method AND the Domain Admin account has the required SQL permissions.
Instead of leveraging a Domain Admin account, we recommend creating a dedicated service account e.g. ‘movere_svc’, that has local admin access to each Windows device, but it is not part of the Domain Admin group, to scan environments on an ongoing basis. This will avoid account lockouts when a user account password is reset and will permit account propagation when Movere is run with its preferred scanning method set to ‘All available’ (default).
SQL access can be granted multiple ways, and even if the appropriate roles and mappings are set to the lowest level possible, the right to login to a specific SQL Server can simply be denied. The items listed below outline the lowest level of access the Movere service account requires to gather the data it requires from a SQL Server:
- Server Role: public
- User Mapping: master (db_datareader); and msdb (db_datareader)
- Securables: Connect SQL, View server state; and View any definition
- Status: Grant: Permission to connect to database engine; and Enable: Login
- Secondary SQL access: Querying SQL databases housing data from sources such as SCCM, SharePoint, vCenter, VMM etc. requires db_datareader to each of the specific database(s)
The account to be used by Movere to scan Linux device(s) will require SSH access and a local home directory. Home directories housed on a distributed filesystem, e.g. NFS used to mount storage to multiple systems are not supported.
IMPORTANT: Movere can scan a Linux device without ‘root’ or a ‘superuser’ account by setting the ‘LinuxSkipSudo’ flag in the ‘Movere.Service.exe.config’ to “true”. The config file is located in the directory where the Console is installed. While superuser access is NOT required, scanning a Linux device that Movere is already running on with a Linux account that does not have superuser access will fail as a non-superuser account will be unable to terminate the existing Movere instance that is already running.
While many customers create individual service accounts for each of these roles (Windows, SQL, Linux) all three can be combined into a single account, if domain-based credentials can be used to authenticate into your Linux systems.
Movere can scan the following operating systems:
- Workstation(s): Windows 2000 Pro (and above)
- Server(s): Windows 2000 Server (and above)
- Linux Device(s): for supported distributions refer here.
IMPORTANT: Movere can both Inventory and collect Actual Resource Consumption (ARC) data from Windows devices. While inventory data can be collected remotely via WMI or locally using the .NET 2.0 (or higher) Framework, ARC data can ONLY be collected from Windows device with the .NET 3.5 (or higher) Framework installed. Remote WMI is NOT supported for capturing ARC data.
Windows device(s) running the Console:
- Inbound: Internal TCP 443 (HTTPS protocol over TLS)
- Internal traffic from endpoint(s) being scanned back to Console (internal use only)
- Outbound: Internal TCP 389 (LDAP) & TCP 3268 (ADGC), External TCP 443
- 443 External for Console, token download from Movere and payload upload via Console
Windows device(s) being scanned:
- Inbound: Internal TCP 445 (Windows file sharing), TCP 135 (RPC), TCP 139 (NetBIOS) & TCP 49152 through 65535 (dynamic port range required to run Bots as a process versus a service)
- Outbound: External TCP 443 (optional for direct upload to cloud from endpoint being scanned)
- Benefit: direct upload to cloud minimizes internal network traffic
IMPORTANT: One way to confirm if the ports required to scan Windows devices are open is by running a test scan against a sample of servers and workstations and looking for 5 key messages:
- Public IP: 184.108.40.206 … When your IP address is visible then the Console can reach Movere’s APIs on TCP port 443. If no IP address is visible, then uploading to Movere will not be possible. From a network connection perspective this appears as a local connection from a dynamic port (49152 through 65535) to a Movere’s API address & port e.g. 220.127.116.11:443 for West US.
- Launching bot PROJSVR.IO.PRIV … The Console is copying the Bots to the targeted endpoint(s), in this case ‘PROJSVR.IO.PRIV’. From a network connection perspective this appears as a local connection from a dynamic port (49152 through 65535) to the targeted endpoint with the label ‘microsoft-ds’ aka Microsoft Directory Services. On the targeted endpoint you will see ports 135, 445, a dynamic port and 443 connection to the Console.
- Service success PROJSVR.IO.PRIV … The Console has delivered the Bots to the targeted device and has successfully launched the FrameworkVerifier to start the scan. If the Bots run as a process (Local Scan) versus a service (default), then this message will not appear, and the dynamic port range (49152 through 65535) must be permitted inbound on the targeted endpoint(s) to allow the process to start.
- Local scan started PROJSVR.IO.PRIV … If the targeted device can establish a secure connection back to the Console on TCP port 443 then a message is sent confirming that the scan has started.
- Cloud upload success PROJSVR.IO.PRIV … When the targeted device can reach Movere’s APIs on TCP port 443 then you will see this connection on the endpoint coupled with a “Cloud Upload Success” message. If the device cannot reach Movere’s APIs directly then the payload will be sent to the Console via port 443 internal for the Console to upload to Movere’s APIs.
Linux device(s), ESXi Host(s), vCenter Appliance(s), XenServer Host(s)
- Inbound: Internal TCP 22 (Secure Shell SSH Protocol)
- Outbound: External TCP 443 (optional for direct upload to cloud from endpoint)
Manual scans & Automated deployment via 3rd party tools
While we recommend using the Console to deliver Bots to targeted endpoints, this isn’t always possible. Movere supports manual placement (copy) and delivery via automated deployment platforms like System Center Configuration Manager (SCCM). To enable both methods of deployment several configuration steps need to be completed (refer below).
The Console must be configured to secure communication with Bots delivered via means other than the Console itself. The first thing that needs to be set is the Maximum number of Devices where you plan to deploy Bots. The default is set to 1000, but this number can be set to any number desired. This setting acts as a limiter and should be set to a value slightly higher than the number of devices you plan to scan. No further security tokens will be released once this number has been reached.
This setting can be altered by opening the ‘Movere.Service.exe.config’ file located in the folder the Console is installed in using a text editor e.g. Notepad:
If the default value is altered, then the ‘Movere.Service.exe.config’ file must be saved. If the text editor prohibits the file from being saved to the same location, save it to an alternative location e.g. Desktop, then manually move it back into the folder housing the Console. You will be asked to replace the existing file confirming that you are placing it in the correct location.
The Passphrase is a secret chosen by the user before deploying Bots manually or via 3rd party tools other than the Console itself. The same Passphrase must be provided both to the Console and the Bots. It can be set either as a command line argument, or via the config file of the respective component (binary): key= “PassPhrase” in Movere.Service.exe.config for the Console, Movere.Bot4.Local.exe.config for Bot4, and Movere.Bot2.Local.exe.config for Bot2.
Since the Bots will try to establish communication with the Console as soon as they start in order to obtain a security token, the Passphrase must be provided before the scans are initiated. Failure to do so will install the Movere service without a Passphrase. If this occurs then the Movere service will need to be stopped, deleted, then re-installed after the Passphrase has been set. There is one exception to this rule which is use of the ‘-noconsole’ flag; allowing the Bots to start without a Console. Further details on using this flag are provided below.
Prerequisites for running manual/3rd party deployments of Movere:
- The Console has already been installed,
- A Magic Word has been set and at least one set of credentials (Windows, SQL, Linux, etc.) have been added via the Console’s “Manage Credentials” tab,
- The Movere Console is NOT running, and it has NOT already been installed as a Windows Service. If it has, then stop the service titled Movere.Service (if running) then delete it from an admin command prompt using the following commands:
sc stop Movere.Service
sc delete Movere.Service
Failure to stop and remove an existing Movere Service will result in all Bots deployed either manually or via a 3rd party tool to fail. The service can also be removed by uninstalling then reinstalling the Console.
- If you are planning to gather both Inventory and ARC data from each targeted endpoint, then the ARC scan must be activated first. The easiest way is via the Console using the following steps:
- Open the Console and enter your Magic Word,
- On the main tab, select the ‘Windows Devices’ and ‘Windows ARC’ check boxes,
- On the ‘ARC’ tab, set the desired duration and frequency of the ARC scan; then
- Close the Console.
You can manually confirm that the ARC scan has been enabled by reviewing the Bot2/Bot4 config files in the Bot2/Bot4 folders located in the directory the Console is installed in:
The ArcEnabled flag should be set to “true”. If it isn’t, then manually set it to “true”.
The ARC interval and duration can be confirmed by reviewing the Arc2/Arc4 config files in the Arc2/Arc4 folders, also located in the directory where the Console is installed:
The name of the device the Console is running/listening on should also be confirmed by reviewing the ServiceHostUrl value:
If the ServiceHostUrl value has not been changed from the default (https://localhost) that implies that you have not run any scans yet. You can set the ServiceHostUrl manually or by running a simple scan (e.g. AD) and verify that the value has been updated to the FQDN of the device where you have installed the Console.
Steps for running manual/3rd party deployments of Movere:
- Open the file ‘Movere.Service.exe.config’ using a text editor e.g. Notepad. This file resides within the folder where the Console is installed.
- Set the ‘MaximumDevices’ number to a value slightly higher than the number of devices you intend to scan. The default is 1,000, but this can be set to any number required:
3. In the same file, set a unique Passphrase. In the screenshot above we’re using ‘Movere.1’, but you will set this to a Passphrase of your choosing.
4. Open both the ‘Movere.Bot2.Local.exe.config’ & ‘Movere.Bot4.Local.exe.config’ files in the Bot2/Bot4 folders which reside in the folder where the Console is installed. Insert the same Passphrase used in step 3. The Passphrase authenticates the Bots with the Console when delivered to endpoints manually or via 3rd party tools:
5. Create a folder e.g. Local, that will house the binaries to be delivered to each targeted endpoint using a delivery vehicle other that then Console. Copy into this folder:
1. The ‘FrameworkVerifier.exe’ file in the FrameworkVerifier folder located in the directory where the Console is installed; and
2. The Arc2/Arc4 folders AFTER reviewing the ARC interval/duration and ServiceHostUrl,
3. The Bot2/Bot4 folders AFTER adding the Passphrase to the Bot2/Bot4 config files in step 4 and AFTER confirming that the ARC module has been enabled,
4. Create a folder e.g. Local, that will house the binaries to be delivered to each targeted endpoint using a delivery vehicle other that then Console. Copy into this folder:
5. The Token.txt file (optional). If the Token.txt file is included in the local package, then each targeted endpoint will attempt to upload its payload to Movere’s APIs directly via port 443 outbound. If this port is unavailable, then the Bots will send payloads back to the Console. To avoid any communications with Movere’s APIs other than the Console, do NOT include the Token.txt file in the local package.
The local package to be delivered to each targeted endpoint should look like this:
6. Install and start the Movere service on the device housing the Console. This must be done AFTER adding the Passphrase to the service config (step 3 above). The easiest way to install and start the Movere service (with the Passphrase in place) is to run a simple scan (i.e. AD) or scan the device the Console is running on (localhost):
After the scan of the device housing the Console has concluded, the Movere service will automatically install and start itself:
7. Copy/distribute the folder created in step 5, e.g. Local, to the targeted endpoint(s) and start the FrameworkVerifier.exe file using the following command:
In the above example ‘consolehost.domain.com’ is the FQDN of the device the Console service is running/listening on. Replace this with the appropriate Console device name on your network.
The FrameworkVerifier will start the appropriate Bot (Bot2 or Bot4) which in turn will contact the Movere Console device (which is listening on port 443) using the Passphrase specified in the Bot config files. If the Passphrases match, then a ‘Token2.txt’ file will appear within the local folder deployed to the targeted endpoint(s). Once this occurs the scan will run. The encrypted payload will then be sent back to the Console for upload to Movere. If the Token.txt file is included in the local package (refer above), then the endpoint will attempt to upload its payload to Movere’s APIs directly via port 443. If this port is unavailable, then the Bot will send the payload to the Console. If all communications with Movere are to occur via the Console, then do NOT include the Token.txt file in the local package.
Support for Multiple Service Host URLs:
The Movere bots will be made aware of and support each fully qualified name and all active IP address(es) for the device running the Movere Console. These will be recorded in the “ServiceHostURL” value in the Movere.Service.exe.config file, which will deliver both the fully qualified name and IP address(es) active of the Console device to all endpoints:
NOTE: This value is set when the Movere Console is installed, but it can be overridden to support the use of load balancers and network names.
Fixing a Service Config file with a bad host name:
If a mistake is made when editing the ServiceHostUrl value and the user wants to reset it back to its original configuration, then blank the key value e.g. “ServiceHostUrl” value = ””. Close and reopen the Movere Console AND scan the device the Movere Console is installed by targeting localhost.
In the screenshot below we have added ‘ERR’ to the end of the Service Host name:
To correct this, either remove the ‘ERR’ entry from the Service Host OR delete the entire ServiceHostUrl value then save and close the service config file:
Next, close and reopen the Movere Console and start a scan against localhost. This will reset the ServiceHostUrl value to its original setting:
NOTE: This option was originally designed to support complex configurations such as load balancers, but it can also be used in situations where the endpoint(s) being targeted cannot resolve the fully qualified name of the host, (this normally impacts Linux devices). By removing the hosts name, in this case ‘JUMP01.IO.PRIV’, all traffic will be directed to an IP address. This is made possible by the addition of the devices IP address(es) as subject alternative name(s) in the Movere certificate, refer above. It’s important to remember that Movere will provide both the hosts name and IP address(es) to the targeted endpoints by default, (primarily to improve Linux scanning reliability), so there is no need to remove the hosts name from the from the ServiceHostUrl value, but it can be used for this purpose if the user prefers.
Direct Token Refresh:
Previously, only the Movere Console could retrieve an upload token from the cloud. This led to some ARCBots timing out after 12 hours due to either a loss of communications with the Console or the inability to reach the Console. The ability to retrieve an upload token from the cloud has now been granted to the Bot4, Arc2, and Arc4 bots running on the targeted endpoint(s) if the endpoint has access to the internet. Direct token refresh for the Bot2 and Linux bots will come in a later release.
Each Bot will still attempt to retrieve a token from the Console first, but if this fails, then the Bot will attempt to retrieve one from the cloud. If either approach is successful then the ARCBot will continue to run for another 12 hours, (the lifespan of the access token remains 12 hours). This also supports situations when the Bots are delivered to the targeted endpoints without using the Movere Console. In these situations, the ARCBot can now run for the desired scan duration without being limited to scanning for only 12 hours, as the bot will refresh the token directly from the cloud.
We advise customers to run the Movere Console as usual and confirm that it is installing a Windows service (Movere.Service) at the end of each scan in order to facilitate propagation of secondary credentials, since these are not available from the Cloud.
Scanning without a Console
The ServiceHostUrl key can also be used to force all ARCBots to talk directly to the cloud and block all traffic back to the Console. Every 12 hours the ARCBots will now be able to download their own ‘Token.txt’ file directly from Movere versus prior versions which relied on the Movere Console to retrieve an updated ‘Token.txt’ file and pass it to each ARCbot internally.
To force all ArcBots to communicate directly to the cloud for payload uploading and token refresh, replace the ServiceHostURL value in the Movere.Arc2.exe and Movere.Arc4.exe with -noconsole:
To manually start the Bots without a Console, replace the host name and port number with the flag -noconsole:
NOTE: When scanning with the -noconsole flag, the Movere bots will be unable to scan SQL servers. Movere does not propagate credentials for SQL access to the bots, and as such scanning without a Console will prevent Movere from being able to access SQL.
Blocking all traffic from the Bots to the cloud:
Multiple upload paths have been built into the Movere Bots to give them the greatest possible chance of delivering the payload(s) they create to the cloud for processing. One of those paths is direct upload from the targeted endpoint to the cloud. In some situations, even though the targeted endpoint(s) can upload directly to the cloud, the user wants all payloads delivered to the cloud via the Movere Console. This can be achieved by manually editing the config files specific to each Bot. We are planning to deliver this as an option via the Movere Console in a future release, but at this time the edits listed below will need to be performed manually.
Open the following config files and alter the URL keys highlighted below. Internally we add a ‘1’ AFTER ‘movere.io’, but any part of the URL can be altered:
NOTE: In this file you also need to remove the GeoApiKey value.
NOTE: In this file you also need to remove the GeoApiKey value.
After these edits have been made, target the endpoint(s) to be scanned. The first “error” message will be “System.Net.WebException”, which relates to the Bots failure to geo-position itself because it cannot resolve the GeoApiUrl address:
In the BotLog on the targeted endpoint you will notice several key messages including Public IP: unknown, Cloud Upload Error: remote name could not resolve, and Local Upload Result: 1.1 200 OK:
In the ARCLog there will be three failed attempts to upload to the cloud followed by a successful upload to the Console confirming that all traffic from the endpoint being scanned is being sent to the Console and not directly to the cloud:
Bot service host logging:
The bot log will now log successful and unsuccessful connections to the Movere Console. As mentioned above, the ServiceHostUrl value can be manually set by the user to any value. In this example ‘ERR’ has been inserted at the end of the hosts name which will not resolve in DNS. The bots delivered to the targeted endpoint(s) will log the failure to connect to the altered service host name, then log the attempt(s) made to connect to subject alternative name(s):
In the bot log below we can see the incorrect host name ‘JUMP01ERR.IO.PRIV’ not resolving in DNS. Movere then attempts to connect to the hosts active IP address(es) (in the order they are listed in the certificate). The bot will make an API call to the host (in addition to PING) as ICMP traffic may be blocked. If a ‘200 OK’ response is received then the host status will be listed as ‘ONLINE’ and communications with the Movere Console will begin:
NOTE: The bot will not automatically attempt to connect on every IP address listed. For example, if 3 IP addresses are listed and the bot successfully connects on the second, then no attempt will be made to connect using the third.
The full command being sent to the Movere Service is now echoed in both the Console and the Service Log. This will improve support by detailing the exact task the user is attempting to perform:
All Movere service events are now captured in a SINGLE ‘Log.Service.csv’ file that is specific to each Movere Console installation. Also, the Magic Word is now masked in the log to eliminate the need to remove these entries from the log before they can be shared with partners and/or Movere support:
NOTE: The ‘FrameworkVerifier.exe’ binary no longer resides in its own FrameworkVerifier folder. This binary was moved into the directory the Movere Console is installed in to make it easier to create a ‘Local’ payload to be delivered to endpoints using products like SCCM.
Terminate an ARC Scan in Progress:
This can be achieved by setting the ServiceHostUrl value to “-noconsole”, then setting the ‘Upload to Cloud’ option to No. Next, run a scan against the device(s) to terminate the ARC scan on. Setting ‘Upload to Cloud’ to No will delete the existing ‘Token.txt’ file on the targeted endpoint(s). By deleting the ‘Token.txt’ file first AND instructing the bots to ONLY send their payloads directly to the cloud, the bots will be unable to establish a connection to Movere and will terminate immediately.
In the screenshots below the ServiceHostUrl value is set to “-noconsole” and the Upload to Cloud option to ‘No’:
Below is a normal BotLog confirming that a connection was successfully established with the Movere Console and the payload produced was uploaded (in this example directly to the cloud):
In the ARCLog we can see the ARC has both run and successfully uploaded its payload (in this example directly to the cloud as well):
By updating the ServiceHostUrl value to “-noconsole” and targeting the device again with ‘Upload to Cloud’ set to ‘No’, we see the new BotLog confirms that the ‘-noconsole’ option has been selected and that there is no ARC Service Host:
Notice that the ‘Token.txt’ file also no longer appears in the Admin share that the Bots are running in. This was automatically deleted by the Movere Service when the ‘Upload to Cloud’ option was set to ‘No’.
Without a Console to upload to, or a ‘Token.txt’ file to upload directly to the Cloud with, the Bot will be unable to upload and will automatically stop and dissolve:
Notices and Disclaimers
Movere® is a registered trademark, and Movere™ is a trademark, of Movere, Inc.
This guide, as well as the Movere® service described in it, is furnished pursuant to license and may be used only in accordance with that license. Except as permitted by any such license, no part of this guide may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, recording, or otherwise, without the prior written permission of Movere, Inc.
The content of this guide is furnished for informational use only, is subject to change without notice, and should not be construed as a commitment by Movere, Inc.
Movere, Inc. assumes no responsibility or liability for any errors or inaccuracies that may appear in the informational content contained in this guide.
Microsoft, Windows, SQL, Exchange, Azure, Office and Office 365, Active Directory, Hyper-V, SharePoint, Exchange, and Lync are registered trademarks of Microsoft Corporation in the United States and/or other countries.
XenServer is a registered trademark of Citrix Systems, Inc
vCenter Server are registered trademarks of VMWare, Inc.