Jump to content

Recommended Posts

Posted (edited)

Difficult topic.... I've added the routing firewall now to the scan subnets. Still no result. Frustrating part is that i can SEE all traffic passing by in the firewall. It scans all IP's and even the IP from the iLO5 device. First ping, then SNMP and after all a port scan to check available ports. So you should expect the device in the list but it does not appear. 

So i've got two questions:

1. It came to my attention the "Found Devices" tab in the probe's Network Devices remains empty. (same at every probe) is this expected?
2. So my situation has at least 3 vlans, connected with a routing firewall. The probe in VLAN "12" is scanning VLAN 11,12 and 14. It is able to find devices in all VLAN's. All except the iLO5 and the WatchGuard Firewalls. The firewall traffic logs show me valid traffic and is allowing all ports.  Tried with both "Enable MAC Address Scanning" on and off. What can possibly be wrong?

I still guess it's because the SNMP scan index being found as 127.0.0.1 and because of the clear explanation from Darren, SNMP scan seems to be the only solution for this setup. 

 

 

UPDATE:

It all seems to be a problem with the devices. After taking a closer look, I found the problem. Now... I need the solution but it's not to solve by Automate. A walk on the iLO5 device shows 2 values when running a walk on 1.3.6.1.2.1.4.20.1.2. the first was 127.0.0.1 and the second was 172.30.30.10. strange part: the IP adres I walk on is 172.30.20.10. So it's a fault by the iLO snmp stack.

Same is for the watchguard clsutered firewall with LAG, BOVPN and Vlans. Walking 1.3.6.1.2.1.4.20.1.2 result in a lot of IP addresses from all interfaces, except the management interface because it's a Virtual IP address. Strangest part is that WatchGuard support tells me this is by design. The only solution is to put the probe in the same vlan/subnet as the VIP from the watchguard to be able to detect it. I'm still working with HPe for the iLO solution.

Edited by Duvak

Share this post


Link to post
Share on other sites
On 4/29/2019 at 9:23 AM, Ben Smith said:

We are seeing exactly the same thing!

I am transforming words from the support, something related here:



The Agent Readiness Check will perform the following:

• PING Check - Pings the target to see if its online. If the ping FAILS nothing more is done.

• Credential Check: A credential check will be made against the potential agent to ensure it has the correct permissions. The credential used here will be the credential defined in the Network Probe > Settings > Push tab; Passwords to Attempt field.

• PSExec push check: This checks the ability access and use the functions of the deployment tool PSExec.

• Agent Installed Check: This will check to see if an Automate agent is already installed on the potential agent. This infers that the potential-existing agent is NOT one of our own. (e.g.: previous MSP's Automate agent left on the machine).

• Service Install Check: We will attempt to install a small-service on the potential agent using the credentials provided (in step 2), to ensure that we have both the permissions and authority required for our Agent Deployment to be successful.

If a machine fails any of these checks, you will not be able to deploy an agent to that machine.

Share this post


Link to post
Share on other sites

I just discovered this thread while searching for: "agent readiness check" failed credentials

This failure surfaced when I enabled the probe on a new client's domain controller. We are only monitoring their servers, so I don't want to push agents to all workstations. I ran the discovery scan to see what other servers they had in their network, thinking I would manually send agent deployment commands to the discovered servers without ever needing to enable "automatic deployment".

However, despite applying the password at various levels (updating config and testing between each change), my readiness checks kept failing, reporting "no valid credentials" as the cause. 

Variations I tested (all failed):

  • Saved the domain admin credentials at the client level, and set them as the default for deployment at the location level (along with service plan selection, etc.)
  • Opened each target Network Device within the thick client, set the Access Password in the Identification pane and saved
  • Opened the Deployment Manager in the thick client and added the credential to the passwords-to-attempt pane on the right, and saved

When I found this thread, Adam's explanation revealed the real problem:

 
 
 
 
 
 
On 6/26/2019 at 3:43 PM, Adam Alsayeh said:

The Agent Readiness Check will perform the following:
...
• Credential Check: A credential check will be made against the potential agent to ensure it has the correct permissions. The credential used here will be the credential defined in the Network Probe > Settings > Push tab; Passwords to Attempt field.
...

After checking the box on the probe settings to Enable Remote Agent Deployment, it allowed me to move the Domain Admin credential into the Passwords To Attempt list, and subsequent readiness checks on servers passed and allowed agent deployments. 

I have noticed, though, that unchecking the Enable Remote Agent Deployment checkbox removes the credential from the right pane and places it back into the left, Stored Passwords pane.

This raises a few questions:

  1. What use are the various password selection fields moving forward? Are these fields deprecated and no longer applicable to any functionality:
    • Network Device Access Password
    • Deployment Manager passwords to attempt
  2. What's the difference between "Enable Remote Agent Deployment" on the probe and "auto-deployment" as I previously understood that checkbox to represent?
    • If I leave that box checked to allow me to manually issue agent deployment commands on network devices, is it going to attempt workstation installs during the next scan?
    • Do I have to manually toggle that checkbox to enable specific deployments while still preventing workstation auto-deploys, or
    • Is there a setting somewhere in the new WCC or thick client probe settings that would allow me to enable deployment but only do so manually (i.e., disable automatic agent push without disabling agent push altogether)?

Not urgent, as I have deployed what I need now, but I would like to get a better grasp of the credential fields requirements and agent deployment functionality moving forward.

Share this post


Link to post
Share on other sites

It does seem silly to have combined the "enable deployment" and password and auto-push options, as for years we manually pushed with the probe if desired.  However it looks like the docs have changed a bit since I last read them? (or I missed this)  https://docs.connectwise.com/ConnectWise_Automate/ConnectWise_Automate_Documentation/090/080/120/100 has an "Agent Deployment Attempts" setting that can be set at zero...does that mean if set to zero it will not auto-push?

Share this post


Link to post
Share on other sites

I missed that too! That seems to answer my question of how to disable auto-deploy without disabling deployment altogether. But I would still like to find out what the other credential selection fields are for.

It would be handy if there was an indication of updated documentation when viewing different agent screens (different color help icon maybe?). Something to reflect "hey, the functionality here has changed". With all of the changes coming through so many facets of the program (in both thick client and WCC), it's hard to look at a changelog before an update and remember all of the inclusions three or four weeks later.

Share this post


Link to post
Share on other sites

Hi JosefNT,

Have you tried to change the probe to run as local account instead of system account? I've never deployed an agent using the probe succesfull without turning this one on first.
And you know... it sounds logic. The local System account on a probe does never have access to network resources. (or you need to use Run As) So once the probe's agent is running as domain admin, it should be able to access every domain computer on the network and deploy the agent. 

image.png.dbcb4ac91b1b24a80217da54f3c393eb.png

So enable the "guy in the box"  icon and try again.

Share this post


Link to post
Share on other sites
7 hours ago, Duvak said:

change the probe to run as local account instead of system account

If the probe is correctly set up to use valid credentials then this isn't necessary.  The probe push basically doesn't work on workgroups unless you jump through a few hoops to allow the remote connection on each PC.  It usually works on a domain.  The probe push connects with the supplied credentials and runs psexec on the remote PC.

Share this post


Link to post
Share on other sites

Hi Steve

I know it should work but it doesnt. Location deployment setting is set and domain admin account assigned in the probe setting. Never been able to push with success untill I run the agent service  with admin account.

Never logged a case for this since there is a simple workaround.

 

Share this post


Link to post
Share on other sites

Thanks @Duvak

Yes, most of our clients on MSP contract have AD environments, so running probes as a local account is SOP in most cases. I was just a bit confused about the differences between Passwords to Attempt fields in Deployment Manager vs. Network Device > Access Password vs. Probe Settings.

I was able to successfully deploy the agent to the servers for this particular client, then simply disable Auto Deployment to prevent pushing to workstations. 

I just wish there was a red asterisk (or some other visual indicator) next to fields whose functionality was altered with a recent Automate update or which were deprecated and no longer serve any purpose. 

Share this post


Link to post
Share on other sites

Finaly... I found at least the ilo5 detection problem origin...

In my case, the iLO5 was in another VLAN. So it will not be available in the ARP table from the probe. This rules out the ARP scan/detection.
But for some reason, the iLO5 device will never respond the IP address from the iLO when checking OID 1.3.6.1.2.1.4.20.1.2.X but the IP address from the Server itself.

So for example: The ilo is configured on 192.168.1.10 and the host has IP 172.17.10.33, the SNMP walk on this oid will show 172.17.10.33. This makes labtech not able to detect using SNMP rules because it does not match the IP address from the Ping Sweep.

In other words: The probe will never detect iLO5 when in another VLAN. So next question: what can do about this.... I keep searching.

  • Thanks 1

Share this post


Link to post
Share on other sites

Great find.  I've an open bug with connectwise on this.  It's with development.  

Share this post


Link to post
Share on other sites
4 minutes ago, NTES said:

Great find.  I've an open bug with connectwise on this.  It's with development.  

But this finding will never be solved by ConnectWise... It's the iLO5 thats reporting the wrong information. So it should be logged with HPe.
However, I logged a case with HPe but they never looked into this because i'm not using a approved tool. Asking what the approved tool should be, they never answered...

Share this post


Link to post
Share on other sites

I'm sure the Dev team can come up with a workaround to the HP issue.  

 

Dell drac seems to have same issue

Share this post


Link to post
Share on other sites
6 minutes ago, NTES said:

I'm sure the Dev team can come up with a workaround to the HP issue.  

 

Dell drac seems to have same issue

No you mention it.... I see. Thats strange. I would understand this when using a shared iLO port. But i'm using dedicated ones...

Hope DEV will find something.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...