How to determine how an asset was detected?

[whoami]

Hello everyone,

Is there a way to determine how an asset was detected by the Lansweeper scan server?

I have a few scanning targets set up including IP ranges, Active Directory, AD OU's, etc. 

Occasionally, I'll notice a few "duplicate" assets and I would like to see how these are distinctly being picked up by my scan server.

For example, I'll have a computer named PC01. 

I'll see it listed twice under PC01 and PC01.contoso.com.

It would be cool if I could click on each asset and see which Scanning Target profile it was detected by.

On a side note, I attached a screenshot of some Scanning Target Profiles I have set up. Is it worth having the AD Computer Path and User Path targets if I am already scanning via the Active Directory Domain target? I'm curious if duplicates may be caused by this or by scanning the same asset again via IP Range.

Any insight is greatly appreciated!

[Bruce_B]

To be clear, there are other scenarios where your Windows computers may be misidentified as Unknown, NAS, etc. Those involve Windows scanning requirements not being met. E.g. if a computer is firewalled to the point where it can only be pinged, it will not be possible to determine its type accurately.

If Lansweeper can connect to a Windows computer via the following ports and has access to the correct scanning credentials, it should be correctly identified:

• TCP 135
• TCP 49152-65535 (WMI port range)

[Bruce_B · Accepted solution]

Duplication issue:

@whoami @mika 
Assets of the type "Windows" specifically have a Scan Time tab, where you can see all applicable scanning targets listed, with timestamps of when an asset was last scanned by which scanning target.

However, since these assets are duplicating I presume that the duplicate is of the type "Unknown" or another type. This usually means Lansweeper wasn't able to retrieve NetBIOS name/domain name from the asset, which is required to create a Windows asset (because it's used for unique identification).

If this happens for some targets but not for others, this likely means that it's not possible to retrieve NetBIOS information without authentication (via TCP 139/445, UDP 137) in your network. This is perfectly fine and is not a hard requirement. But it does mean that if you're scanning via an IP Range scanning target, you'll need to map your Windows scanning credentials to these IP ranges. NetBIOS mappings (to domain name or computer name) will not be functional in this case, as it requires the system to be able to retrieve the name, which we already established it can't in this particular scenario.

AD scanning targets won't be affected by this scenario, because the starting point involves connecting to AD, where both NetBIOS name and domain are available.

TLDR; try mapping your Windows scanning credentials to all IP ranges that contain these Windows computers.

AD target question:

@whoami

All available AD targets behave differently and have different purposes. There is no real downside to having all 3 types running at the same time.

• Active Directory Domain Scanning targets will only scan computers that haven't been scanned recently, which did logon to a domain controller recently. This target is ideal for scanning computers that have unreliable activity, and don't fit within a schedule.
• Active Directory Computer Path is a scheduled target, but it also crucially creates assets for computers that are not currently online or are not currently scannable for another reason. This makes sure your entire AD is inventoried, regardless of the ability for a more direct, complete scan.
• Active Directory User Path ensures all of your users and groups (within the scope of the target) are scanned. Without this target, you'll only scan users that are found to be logged on to Windows computers as they're scanned, this will likely lead to an incomplete AD user inventory.

Lansweeper has a built-in cooldown, which prevents it from querying the same AD object more than once every 20 hours, this serves to prevent any AD performance impact which could otherwise theoretically be caused by having many duplicate targets.

[mika]

Facing exactly same issue. The PC01.contoso.com would also come as unidentified (also having RPC issues),  where PC01 gets scanned correctly.