Prepare targets once. Scan from VunFisher.

1. Know which computer you are using

The Windows scan account is separate from your VunFisher login, activation email and Developer license. Never place a password in a deployment script, spreadsheet, command line or screenshot.

2. Tenable and VunFisher: apply the right requirements

This comparison summarizes the linked Nessus guide; it does not claim equivalent detection coverage.

Gaps addressed in this edition: account ownership, policy conflicts, per-source firewall restrictions, fleet deployment, scanner-versus-target instructions, credential preflight, rollback boundaries and acceptance evidence. Read the Tenable source.

3. Prepare before making changes

1. IT owner: approve target scope, scanner addresses, account privileges and a maintenance window.
2. Target: use 64-bit Windows PowerShell 5.1 on a Windows Pro/Enterprise/Education workstation or member server. Domain controllers and Home editions are outside this pilot's support claim.
3. Network: identify fixed private IPv4 addresses for the scanner. Keep devices awake on an approved LAN/VPN. Do not expose WinRM through internet port forwarding.
4. Account: provision a dedicated approved account through IT. Prefer a managed domain account or group limited to the target scope. Avoid Domain Admin for ordinary workstation scanning.
5. Workgroup: create a unique local account using Windows Settings → Accounts → Other users, or your approved management tool. Use its Windows password, not a Windows Hello PIN. The assistant can add an existing account to Administrators after approval; it does not create or store passwords.
6. Policies: check network-logon rights, denial policies, NTLM restrictions, endpoint-security rules and network isolation. Do not turn off antivirus or globally disable the firewall to make a test pass.
7. Existing management: review other WinRM users. Apply disables built-in WinRM firewall rules and replaces their access with a scanner-scoped rule; this may interrupt existing management. Use centrally managed rules instead if other tools need broader approved access.

4. Install and use the assistant on one target

4.1 Install

1. Extract the complete setup ZIP into a folder on the target. Keep all files together.
2. Run INSTALL.cmd. It checks package hashes, installs under your Local AppData folder and creates VunFisher Target Setup on that user's desktop. Installation alone does not enable remote access.
3. Open the shortcut and approve the Windows administrator prompt. Organization execution-policy restrictions are not bypassed by policy changes; ask IT to sign/approve the package if it is blocked. The launcher uses a process-only execution-policy setting for this unsigned pilot.

4.2 Review

1. Click Audit this target. The assistant opens Credential scan setup with ordered, target-specific steps based on network profile, domain role, WinRM status, firewall-rule origin and local-account policy. Resolve every STOP condition before continuing.
2. Use Audit summary for the numbered evidence and Technical output / plan for raw data and the exact preview.
3. Enter the scanner's private IPv4 address, or comma-separated addresses. Do not enter a subnet or wildcard.
4. Enter DOMAIN\scanuser or TARGETCOMPUTER\scanuser. For a local account, select the explicit local-account approval checkbox.
5. Click Preview changes. Stop if the plan conflicts with an existing management policy. Public networks and policy-managed WinRM are blocked by the local assistant.

4.3 Apply after pilot approval

1. Click Apply approved plan and read the confirmation. It grants administrator access if needed, configures Windows remoting and scopes the tool's firewall rule.
2. Save the printed checkpoint folder. Checkpoints are protected for Administrators and SYSTEM under C:\ProgramData\TXCyber\TargetSetup.
3. A local success message means local configuration completed. It does not prove that the scanner can authenticate or collect all evidence.

The assistant keeps UAC enabled, does not enable Remote Desktop or Remote Registry, does not add shares, and never changes antivirus settings. Other custom firewall rules can still permit access; IT must review the effective policy.

5. Finish setup on the scanner

5.1 Confirm the connection model

The current VunFisher collector uses Negotiate over HTTP WinRM. Microsoft documents message encryption after authentication, but IP-address/workgroup connections do not provide Kerberos server identity. TrustedHosts is an exception list, not identity verification. VunFisher's current collector has no HTTPS/UseSSL option; if policy requires certificate-validated WinRM or disallows NTLM, do not weaken that policy—this collector needs a separate enhancement. Microsoft security guidance.

1. From the scanner, test the approved target address using Test-NetConnection TARGET_IP -Port 5985. Replace TARGET_IP with the target's actual address.
2. For an approved IP/workgroup workflow, ask IT to inspect WSMan:\localhost\Client\TrustedHosts and add only the exact intended targets if required. Preserve existing entries and record changes. Never use *. This is a scanner-side setting; the target assistant does not alter it.
3. Open VunFisher → Credentials → Create Credential Profile.
4. Choose Windows WinRM; enter the actual scan username, domain or target computer name, and port 5985. Create a unique password reference for each distinct secret.
5. Under Add Windows Password, select the saved profile and enter the Windows account password privately. Optional DPAPI remembering is tied to the Windows user running VunFisher.
6. Under Test Connection, enter the target IP, choose the profile, confirm authorization and run the test.
7. Expect successful connectivity, authentication, identity and required privileges. Then run a Credentialed Windows Assessment for the exact approved scope.

6. Active Directory: configure a fleet with GPO

1. Create a dedicated scan security group and add the approved scan account. Use a test OU containing one or two member computers first.
2. Use an additive Local Users and Groups preference or your established group-management policy to add that scan group to the targets' local Administrators. Do not replace the entire Administrators membership list.
3. Configure the WinRM service/listener through an IT-owned GPO. Use the Windows Remote Management service policy and the required Windows PowerShell endpoint. A listener IPv4 filter selects local listening interfaces; it is not the remote scanner allowlist.
4. Configure the inbound firewall policy separately: TCP 5985, Domain/Private only, remote addresses limited to approved scanners. Review competing rules that could allow broader access.
5. Retain encrypted-message requirements and approved authentication settings. For a domain identity, do not introduce the local-account UAC exception by default.
6. Apply the policy to the test OU. Confirm effective results with gpresult /r, target Audit and a scanner-side credential preflight.
7. Expand in controlled batches after acceptance. Store the GPO backup and rollback procedure; reverting local settings will not override an enforced GPO.

Use the assistant in Audit mode on managed machines. Its local Apply deliberately refuses policy-managed WinRM; GPO is the authoritative configuration path.

7. Intune: scope policy to device groups

1. Create a pilot device group and exclude domain controllers and business-critical endpoints until specifically reviewed.
2. Use Settings Catalog/Endpoint Security profiles for WinRM, firewall and local-group membership where available. Review existing security baselines for conflicts.
3. Scope the firewall to approved scanner IPs. An Entra-only device is not automatically a Kerberos/domain-authentication target; approve its credential model separately.
4. Distribute the assistant as an approved Win32 content package or run Audit through a managed script. Use 64-bit Windows PowerShell and the intended SYSTEM/admin context; do not embed account passwords or share one local password across the fleet.
5. If IT chooses scripted Apply on an otherwise unmanaged configuration, review the exact Plan, sign the script and run in a maintenance window. Policy-managed targets should remain on the policy route.
6. Collect return status and checkpoint locations through Intune's reporting. A script-success status is not proof of authenticated scan coverage.
7. Validate from the scanner, then expand device groups gradually. Remove assignments and restore the prior managed policy if rollback is needed.

LAPS can manage unique local passwords, but VunFisher does not currently retrieve LAPS secrets automatically. An authorized operator must use the current password through the normal credential workflow. Do not promise unattended rotation handling.

8. Standalone/workgroup and command-line deployment

1. Prepare a unique approved local account on each target.
2. Run the assistant locally, using the target's computer name in the account. Approve the local-account exception only if needed.
3. Configure exact target entries on the scanner where TrustedHosts is required; keep the list limited and documented.
4. Store distinct secrets separately in VunFisher. Coordinate password changes before scheduled scans.

Example for an IT-managed pilot

Replace both example values. Run locally on each target in elevated Windows PowerShell 5.1. A domain account is shown; workgroup targets also require -AllowLocalAccount.

.\TargetSetup.ps1 -Mode Audit
.\TargetSetup.ps1 -Mode Plan -ScannerAddress '10.20.30.10' -ScanAccount 'CONTOSO\vf_scan'
# Run only after the plan is approved:
.\TargetSetup.ps1 -Mode Apply -ScannerAddress '10.20.30.10' -ScanAccount 'CONTOSO\vf_scan' -ApproveChanges

The script does not push itself to remote computers. Use GPO, Intune or your approved endpoint-management tool for distribution. No fleet has been configured automatically by creating this package.

9. Acceptance checklist before widening deployment

1. Use a disposable Windows VM: record its original firewall, WinRM and group settings.
2. Run Audit and Preview. Confirm that both leave remote-access settings unchanged.
3. Apply with one approved scanner. Confirm TCP 5985 and authentication from that scanner, then confirm a different source is denied by effective firewall policy.
4. Verify the actual account identity and administrator evidence, then run one authorized assessment.
5. Reboot the target and reopen VunFisher under the same scanner Windows user. Repeat credential preflight and a scan.
6. Test Undo; compare the restored access controls and document retained WinRM components. Test a failed Apply and recovery from its checkpoint.
7. Repeat the relevant test for AD, Intune and workgroup. Review application/management impact before fleet expansion.

Current scanner jobs are bounded private IPv4 scopes, up to 256 addresses per job. Fleet preparation does not increase scan-engine capacity. Divide larger estates into approved jobs and maintenance windows.

10. Undo and uninstall

1. On the same target, open the assistant as Administrator and choose Undo using checkpoint.
2. Select the exact folder printed by Apply. Confirm restoration of captured access settings.
3. Review the result. WinRM service, listeners and session endpoints remain enabled; IT must decide whether they are shared and can be disabled. Undo is not a complete remoting uninstall.
4. If the assistant reports an incomplete undo, retain the checkpoint and use local administrator access. The temporary blocking rule may remain in place intentionally.
5. Restore scanner-side TrustedHosts changes separately if no longer needed.
6. Uninstalling the assistant means removing its own Local AppData tool folder and shortcut. It does not undo configuration. Retain checkpoints according to your organization's retention policy.

Run Undo promptly after testing and before unrelated policy changes. A snapshot may restore earlier settings over later changes; review the plan and checkpoint with IT first.

11. Troubleshoot in order

12. Resource links and support

• VunFisher website
• Published VunFisher Windows download
• Tenable: Credentialed Checks on Windows
• Microsoft: WinRM security considerations
• Microsoft: Windows PowerShell Enable-PSRemoting
• Microsoft: WinRM policy configuration
• Microsoft: Intune Win32 deployment
• Microsoft: local-group membership policy

Website publication of this new assistant and guide is pending. Until published, use the guide.html and setup package supplied together. Existing public downloads do not yet contain this assistant.

Support evidence: tool version, Windows edition, target/scanner roles, failing stage and sanitized error. Share no passwords, recovery keys, DPAPI files or activation codes.