→ 🚀What's New? Join Us for the Fall Product Launch! Register Now !

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
zhongjiedong
Engaged Sweeper II
So we decided to go with a service account for scanning, we made it with a huge randomly generated password so it's not easily guessable and set it to work. Now we are getting access denied issues while it's trying to scan while it was fine using my admin credentials.

Here is the log from connection tester:

Lansweeper Connection Tester 6.0.0.3

Scanning Lansweeper Service (on this machine)..
Status: Running
Version: 6.0.0.65

Pinging tba-stn0080
Ping ok.

Scanning TCP ports..
135 open (EPMAP)
139 open (NetBIOS Session Service)
445 open (SMB)

Checking DNS..
tba-stn0080 resolved to: 192.168.49.179
If this is not correct, please check for DNS problems.

Checking reverse DNS..
192.168.49.179:
tba-stn0080.tba.local

Scanning netbios (UDP)..
Computername: TBA-STN0080
Domain: TBA

Scanning Active Directory..
operatingSystem: Windows 10 Enterprise
operatingSystemVersion: 10.0 (14393)

Scanning WMI..
Computername: TBA-STN0080
If this is not correct, please check for DNS problems

Operating system: Microsoft Windows 10 Enterprise
\root\cimv2 Remote WMI access test OK

Operating system: Windows 10 Enterprise
\root\default Remote WMI access test OK

Checking C$ Access
Deployment Folder: OK
Access Rights: OK

Checking Task Scheduler
The network path was not found. (Exception from HRESULT: 0x80070035)

Done.


I honestly have no idea what is going wrong, the server is not logging these events either so that log file is useless.

Interesting extra, here are the logs from my admin account that works for scanning:

Lansweeper Connection Tester 6.0.0.3

Scanning Lansweeper Service (on this machine)..
Status: Running
Version: 6.0.0.65

Pinging tba-stn0080
Ping ok.

Scanning TCP ports..
135 open (EPMAP)
139 open (NetBIOS Session Service)
445 open (SMB)

Checking DNS..
tba-stn0080 resolved to: 192.168.49.179
If this is not correct, please check for DNS problems.

Checking reverse DNS..
192.168.49.179:
TBA-STN0080.tba.local

Scanning netbios (UDP)..
Computername: TBA-STN0080
Domain: TBA

Scanning Active Directory..
Error: The user name or password is incorrect.

Scanning WMI..
Access is denied, please check your credentials.

Access is denied, please check your credentials.

Access is denied, please check your credentials.

Checking C$ Access
Connection Failure. Error: The referenced account is currently locked out and may not be logged on to

Checking Task Scheduler
Access is denied, please check your credentials.

No Kerberos Errors in eventlog.
Done.
4 REPLIES 4
Bruce_B
Lansweeper Alumni
It could be that a policy hadn't applied yet, though that's just a guess.
zhongjiedong
Engaged Sweeper II
Problem solved after a server reboot. Not sure why though :s
zhongjiedong
Engaged Sweeper II
I found it strange as well and now doing the test with zhongjie.admin shows as all successful (apart from the task scheduler part)

I will have a look at the password length and see if that's causing the issue

Also, correction: both logs are using the service account with the randomly generated password. The first log shows a server and the second just a standard workstation.

Why would the credentials work on a server but not a workstation?
Bruce_B
Lansweeper Alumni
If I understood you correctly, the first connection tester was run using the admin account with the "huge randomly generated password" while the second one was run from your admin account. Is it possible that you've switched the order of the 2 tester outputs? Considering the connection tester output of these testers seems to be the opposite of what you're describing.

It's not clear exactly how long this randomly generated password is, but do note that the effective length limit of passwords within windows is 127 characters (Microsoft limitation), if the password exceeds that length, that may be causing the issue.