Jump to content
[[Template core/front/profile/profileHeader is throwing an error. This theme may be out of date. Run the support tool in the AdminCP to restore the default theme.]]

Duvak last won the day on August 21

Duvak had the most liked content!

Community Reputation

3 Neutral

My Information

  • Agent Count
    200+

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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...
  3. 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.
  4. 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.
  5. 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. So enable the "guy in the box" icon and try again.
  6. 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.
  7. Hi Darren, Thanks for taking the time to explain the principles of the probe system. This made me think a bit more out-of-the box. Yes, the situation is not only a different subnet, it's a different VLAN. So thats why ARP doesn't show the devices. So next is de SNMP scan. My probe is configured to not scan it's own gateway (which is the firewall) because the management IP for the firewall is in a different VLAN. So i've added the gateway IP to the probe settings. Now I have to wait and see if the probe will learn. I'll keep you updated.
  8. Hi Darren, The problem is with both MAC disabled and Enabled. Because when I do a arp -a on the probe, it does not show the IP address from the iLO of Firewall. Even when I visit the site or ping it, it will not appear in the ARP table. So following the scan method: step 1: netbios. All ports are open but no show. And Step 2 (SNMP Check): Sorry, i've been not very clear. Let me show you. This is a SNMP Walk to a firewall device scanning from another subnet: You see index 1 is bound to 127.0.0.1. Scanning from the same probe a Switch for example, it shows me this: That's what we want to see. So we've got a visual on whats going wrong in the detection according to step 2 in Q10 in this post. So the alternative would be Step 3, Arp scan. However, the iLO device/watchguard firewall device does not show up in the ARP table. Even when i Ping it of visit the website.i'm not that familiar with ARP so I guess this is expected behavior when a device is in another subnet? So you see: even when all requirements are met, the device will not show up in the networkdevice list.
  9. Hi Namik, Can you verify if your probe is on another network segment as the Esxi hosts are? I discovered something strange in this setup and reported it to CW support. It's been escalated to DEV in the meantime. There's the same with iLO5 and WatchGuard firewalls. Let me sketch the situation: "Got a probe in network 192.168.1.0/24. The probe has just one network interface. Traffic to another network is being arranged by a routing switch or firewall/router to the segment 192.168.2.0/24. The probe is scanning both subnets. It has no problem with 192.168.1.0/24 but in the other network it does not find all devices. All ports are open." I found it has to do with the detection method from Gen2 Probes. It's being explained in Q10 from this topic. When manually discovering a... let say HP iLO5 in this case, it finds the IP address. So it starts to find the index table from the device. However, the first available index refers to 1.3.6.1.2.1.4.20.1.2.127.0.0.1. So the probe is confused... is it me? not sure.. what to do? ah just leave it. Now, when you assign another NIC to the probe and add network segment 192.168.2.0/24 to it, the probe seems to be smart enough to use that one to scan instead of routing the traffic. But when you scan the device now, the first available index refers to 1.3.6.1.2.1.4.20.1.2.192.168.2.30. Now it know what to scan and the device will show up in the network device list. This is a known issue and logged with 11576922. (https://university.connectwise.com/university/reports/automateknownissues.aspx) My originating ticket was 11737449 and was merged into this one. I've never mentioned a Esxi host but only WatchGuard firewalls and iLO5 devices. But they told me it's the same problem. It seems like a fix is being written because the status is "review by PM".
  10. Hi All, I'm asked to detect the difference between MSSQL Express Edition (free) and payed versions. So after a long search I found how to detect the difference. A powershell query like: "Get-WmiObject -Namespace root\Microsoft\SqlServer\ComputerManagement11 -Class SqlServiceAdvancedProperty | Where-Object {$_.PropertyName -eq 'SKUNAME'} | select PropertyStrValue | format-list" will return Express Edition (or another editions). This is the one for SQL Server 2012... other versions need to look at another version of ComputerManagement but in the end it will return the version. So I had a good idea, lets make it a role detection rule! But there's something I can't get to work. So who can tell me what i'm doing wrong? It simply will not detect the express editions... Why?! Role Detection MSSQL Server 2012 Express.sql
  11. Hi Martyn, Big fan of the Gen2 probe. So good work. I've got one question about monitoring snmp or Collecting SNMP info using emplates. Hope you can give me an example so I can use it in my search to knowledge because there's no info on the documentation site from Automate. There's a firewall. Lets call it a WatchGuard firewall. 😉 A Walk on the firewall shows me a ton of information but the information has a lot of variables. So there's no static OID to monitor. There's a Index table showing me indexing numbers for the next tables. The next table is the name table. Relating to the index above. The next table is the Status. Also relating on the index above. Is there a way to do this: Look for the name in the Name table. Find the index related to this name, find the status related to the index. Let me show: 1 find oid with value IKED 2 Find related index 3 Find status from this value with the related index. I guess this should be able with the SNMP Collection Templates and Sub Procedures. However..... how? Hope you can point me in the right direction. Kind regards, Bas van der Zanden
  12. Hi Wupsje, Did you know you can also use the group by function? It saves you typing a lot of queries. Example: SELECT NOW() AS "time", computers.os as 'Operating System', COUNT(ComputerID) AS 'Number' FROM computers GROUP BY computers.os order by (Number) desc Use this as Query A, remove B,C,and the rest and you've got yourself a nice Pie
  13. Confirm! works fine. Was not aware the patch was pulled so installed it yesterday. Wish I was notified....
  14. Hi Fellow Geeks, I found some default script in CW Automate that will fail by default. I've reported them to CW Automate Support but one of them is exceptional and I want to share my findings with you guys. So the scripts that will fail by default: Exchange Database Report (This is the one i'd like to share with you below) Backup and Report on GPOs (Line 18 does a folder check but because trailing slash is missing it looks for a file) Exchange User Email Stats (Line 44 and 46 does a folder check but because trailing slash is missing it looks for a file) Exchange 2010 Best Practice Report (Line 33 does a folder check but because trailing slash is missing it looks for a file and a typo in line 34) Exchange Environment Summary (Line 31 en 33 does a folder check but because trailing slash is missing it looks for a file) So for the last 4 scripts, adding a trailing slash will solve the script problem. However, solution center overwrite this so i've reported them to CW Automate support. However, the first one: Exchange Database Report is some more advanced. The script fails on exchange servers with larger databases. It calls a powershell script Exch2010DB.ps1 and verifies the MD5 hash to make sure the file is not been modified. This powershell script is pulling some data from the exchange environment like database size. This is where the problem happens because the database size is tagged as [int] and so only handle 32bit values. Larger databases exceed this number and so the PS1 will fail. I was able to fix this by simply modifying the PS1 file and make [int] and [int64] (line 131, 137, 167). However, the file is being checked in the CW automate script by the MD5 hash. So modify the PS1 and the hash is different and will fail again. So disable the hash check functions from the script is a solution (?). And this will also be made undone by Solution center updates. But now the big question: CW Automate support states the PS1 script is not developed by CW Automate and therefore will not be changed by them. I do understand this in a certain way, but a user cant change this as well because it's being overwritten by solution center. So i've asked them now to change the CW automate script to remove the MD5 hash check part so users can modify the PS1 script. Waiting for an answer so I hope they will understand and apply my request. But what if they don't? Users cant change it, CW support won't. So in the end, CW Automate is provided out of the box with a failed script? Whats you opinion? Kind regards, Bas van der Zanden
  15. It sure does. The map makes sense when all devices are detected correctly. But the new probe system does not make any changes in the device detection. it makes use of the same tables with device information. About the regex in the detection templates: It's not that hard. All i used where (?i) and ^. ^ when it need to match an OID like ^1.3.6.1.4.1.11.2.3.7.11.153. ^ means this is the start of the string. So ^1.3.6.1.4.1.11.2.3.7.11.153 detects a HP Procurve J9727A (?i) when the result contains text. It means don't bother about case sensitivity. So (?i)CF378A detects a HP Color Laserjet M477fdn that has the model number CG378A and can be detected even if the model is cg378a. And there's an exact match so the regex is CF378A. This must then be an exact match including upper/lower case.
×
×
  • Create New...