WinRM
Windows Remote Management (WinRM) is the preferred protocol used in vScope for inventorying Windows-based operating systems. WinRM is a Microsoft implementation of WS-Management Protocol, Read more, and allows vScope to collect detailed data about Windows resources, such as system hardware, software, and configurations, with more efficiency and security than WMI.
WinRM in vScope
vScope defaults to WinRM for discovery on Windows systems, as it provides a more robust and secure alternative to WMI. WinRM is generally faster and more resilient than WMI, especially in environments with high network latency.
It allows for better inventory of systems running Windows compared to WMI and is relatively easy to setup. It can be done through a GPO in your Active Directory.
Requirements
- User Account: Ensure the account used for WinRM discovery has the necessary permissions on the target Windows systems.
Change Location for Scripts
vScope uses temporary folders to store scripts during the inventory process. There are two key locations for these temp folders: the vScope server itself and the remote Windows servers (for WinRM-based discovery).
Temp Folders on the vScope Server
To specify a custom temporary folder for storing scripts on the vScope server, add the following lines to the config.ini
file, located at C:\vScopeData\configuration\config.ini
:
If the specified custom path for the temp folder on the vScope server encounters any issues (e.g., access or write permissions), vScope will automatically revert to its default temp folder. Ensure that the custom folder path:
- Exists on the vScope server.
- Has write permissions for the account running the vScope service.
Temp Folders on Remote Windows Servers (WinRM Only)
When using WinRM to inventory Windows machines, vScope executes PowerShell scripts in a TEMP folder on each remote machine. By default, this TEMP folder is defined by the $env:temp environment variable, which typically resolves to:
Changing the Remote TEMP Folder for WinRM PowerShell Scripts
To specify an alternative TEMP folder location for PowerShell scripts on remote Windows servers, add the following line to the config.ini
file on the vScope server:
Replace [YOUR_DESIRED_PATH] with the path you want vScope to use for temporary files on remote servers. This path must:
- Exist on the remote servers where vScope is running inventory tasks.
- Allow write permissions for the user account specified in the WMI credential.
- For example, you could specify:
Ensuring Permissions
Permissions are crucial for vScope’s inventory process, especially when using a custom temporary folder on remote machines for PowerShell script execution. To ensure the setup runs smoothly:
-
Verify Folder Permissions: Confirm that the specified folder path (
C:\CustomTempFolder
or your chosen path) grants read and write permissions for the WMI credential user across all target machines. This user must be able to create, read, modify, and delete files within this folder. -
Testing Access: Manually log in as the WMI credential user on a remote server and attempt to create and delete a test file in the specified TEMP folder. This will help confirm that vScope’s inventory operations won’t encounter permission errors during discovery.
-
Administrative Privileges: If the custom TEMP folder is not accessible due to permissions issues, consider adjusting the user privileges or selecting a different folder that is universally writable by all users, such as
C:\Windows\Temp
. However, note that using theC:\Windows\Temp
folder may require administrative rights on some systems. -
Check Network Policies: Ensure network policies or group policies do not restrict access to the designated folder path. Some environments may restrict access to certain folders for security reasons, impacting vScope’s ability to write temporary files.
Additional Notes
-
Folder Clean-up: vScope is designed to remove temporary files after each inventory process. However, regularly check the custom TEMP folder to ensure it does not accumulate unused files, especially if permissions or network issues interfere with cleanup.
-
Config File Changes: Any changes to
config.ini
require a restart of the vScope service on the server for the new settings to take effect. -
Environment-Specific Paths: If you manage a diverse environment with various operating systems or folder permissions, consider using a folder that is consistently available across all systems, or set individual paths in
config.ini
as needed.