Hi Geert,
Thanks for the quick response. As you describe below, the plan for v4 is to allow > LS (1) scans Domain (A), and LS (2) scans Domain (B). This still will pose an issue in most Enterprise environments where Domain (A) lives in Data Center (A) and Data Center (B), and possibly others.
In the above scenario, as outlined in the attached PDF, the following takes place... (Due to security concerns Lansweeper Service "LS (X)", can only reach local clients)
1. LS (1) scans clients in Domain (A) in Data Center (A)
a. The data collected by LS (1) is sent to LSDB
b. "RPC Server unavailable" flag for clients in Domain (A) in Data Center (A) is set to FALSE
2. LS (2) scans clients in Domain (A) in Data Center (B)
a. The data collected by LS (2) is sent to LSDB
b. "RPC Server unavailable" flag for clients in Domain (A) in Data Center (B) is set to FALSE
c. LS (2) re-scans clients in Domain (A) in Data Center (A)
d. "RPC Server unavailable" flag for clients in Domain (A) in Data Center (A) is set to TRUE (This, of course is a false positive)
After the initial Active Scanning client discovery, the process starts all over again on the next polling cycle. Step 1 will resemble Step 2 at this point.
An additional consideration will be needed to address clients in "Workgroup Mode". In the drawing, having the ability to be able to assign LS (4), through lsclient.exe, to only scan those non domain clients in Data Center (D) would be extremely helpful.
Of course there are other types of configurations that could be presented here, but with the ability for Active Scanning to use AD Sites, and/or AD Computer Account Location information (already collected by LS), to target domain members, and lsclient to target non domain clients, gives Lansweeper the ability to scale into most, if not all complex enterprise models.
Basically, the idea here is to have each instance of the "Lansweeper Service" to have "ownership" of it's own clients, and only scan those clients.
Your thoughts?