Mike Moniz

Members
  • Posts

    220
  • Joined

  • Last visited

  • Days Won

    47

Everything posted by Mike Moniz

  1. I don't expect you would lose any history or settings in LogicMonitor. Likely just gaps in monitoring during your migration. LM doesn't talk with AD/LDAP for information so it's not going to just suddenly delete everything. If the Collector is not able to talk with the server for any reasons, it just will keep trying until it can and just have monitoring gaps. You can decommission the server completely and LM will still attempt to gather data until you remove it from LM itself. Is the Collector server also moving domains? I would just restart the Collector services to make sure it can start properly or if it needs it's login credentials updated. If you use SSO with LogicMonitor that might be affected by this domain change, you might want to look into that but I'm not familiar with that part. If you are worried about details or need to complete a full ITIL change ticket or the like, it might be worth talking with LM Support or your rep who I think can look at your specific situation.
  2. I'm going to assume you mean that a Windows system will be changing to another Active Directory domain? The biggest issue likely will be due to credentials. Windows monitoring uses WMI and typically using a local/domain admin account on that system. You want to make sure the credentials either continue working (like if there is trust between domains) or you update the credentials to use the new domain, either on the collector itself if it also changed domain or the wmi.user/wmi.pass properties.
  3. Thanks. I did some testing but the only functions that seem to work as domain aggregation, where you get a straight trend line, is percent and rawpercentile. The other functions seems to use the point-in-time value rather than all the data displayed, unless you do something that always outputs the same value regardless of the datapoint value, like just providing a static number. Cool that you can use something like percent(datapoint,100) and percent(datapoint,0) to get the max and min of the graph shown though! Thanks!
  4. Do you mind going over what you mean a bit more? Are you talking about percent/rawpercentile functions? I thought that aggregations (sum/min/max/ave) was across multiple instances/devices but not across time. Thanks!
  5. You can also look at breaking LM's auto detection of MSSQL by disabling the PropertySources that apply the MSSQL category like addCategory_MSSQL (there might be more). You will need to manually cleanup any existing MSSQL devices to remove existing MSSQL categories. But doing that then let you selectively add the MSSQL category manually if you have a few servers you do want to monitor later. This is likely less important for businesses but super useful for MSPs.
  6. Kinda. The Gauge widget has a Peak option. It only applies to one datapoint/device at a time though so if you need a lot of them it's not that great. The graph widget can show min/max/ave in the legend but I'm not aware of a way to force that to always show on page load.
  7. ...or how to get LogicMonitor pass WMI/DCOM Access Denied Messages I've been dealing with monitoring some systems that are either not joined to the domain or where the LM service account is not allowed to be a domain admin. There are guides from LM and more general online posts for various workarounds but not always describing what exactly these changes are doing and which parts are really needed for your needs. So I put together this post on my notes. Please review the comments on this post for any corrections and comments. Note that I don't work for LogicMonitor so this is based on my understanding, research and testing. Please let me know if you see any mistakes or misunderstand anything. -Mike How LogicMonitor monitors basic Windows systems LogicMonitor uses WMI and WinRM ("Get-CIM*") requests to monitor Window Servers, with WMI being the most used. WMI requests over the network use DCOM technology which communicates over RPC on the network. To make WMI queries over the network, you need to have permissions within DCOM/RPC and WMI. Access to DCOM is controlled by dcomcnfg.exe and WMI access is controlled by Computer Management > Services and Applications > WMI Control. WinRM access is simply controlled by being in the Remote Management Users group. User Account Control (UAC) To complicate things further, UAC (User Account Control) is applied on both local and remote network access. UAC is designed to de-elevate any administrator user so they get normal user permissions. You can effectively think of it as removes your user from the Administrators group on-the-fly for your request. When working locally with UAC on, you can regain full administrator privileges by using "Run as Administrator" or disable UAC notifications in the control panel. Disabling UAC notifications will have the shell auto-elevate for you. Setting the UAC slider in Control Panel to "never notify" will not disable UAC but just remove the notification and auto-escalate locally. The slider does NOT affect remote UAC use and it will still apply in full force. The effect of UAC on remote connections will also depend on if the remote server is joined to a domain or not. When a server is joined to a domain, any local administrator (which includes domain admins) making remote calls will run with full administrators privileges. Basically, UAC will not affect remote network access on domains. When a remote server is not joined to a domain, just a workgroup, then UAC takes full effect on remote access for all local administrators except the built-in "Administrator" account. So if you use a dedicated monitoring account (as suggested) that is a member of the local Administrators group, UAC will effectively remove administrators group access from the monitoring account remote access. There isn't a way to "Run as Administrator" with WMI remote requests. UAC's Effect on DCOM and WMI By Default, recent Windows versions provide the following permissions (simplified for our purposes): * Remote DCOM: Administrators, Performance Log Users, Distributed COM Users * Remote WMI: Administrators So by default Windows only allows those with administrators privileges to access WMI remotely. If you are a normal user you will be blocked by DCOM before you get to WMI. But if you were part of the Performance Log Users or Distributed Com Users, you would get past DCOM. When remote UAC is in effect, UAC will remove your Administrators permissions as mentioned above. This causes you to be blocked by DCOM anyway unless you are also part of those two groups. Doesn't matter if you are part of the local Administrators group. There are two ways you can allow access: 1) Fully disable UAC by setting the EnableLUA registry value to 0 and reboot. This will fully disable UAC in Windows. This would stop UAC from removing administrator privileges, allowing access to anything that allows access to administrators. If you want to have full administrator access for monitoring I would suggest this option. 2) First modify WMI Control to allow your actual account to remotely query WMI. Then either add the account to the Performance Log Users or Distributed COM Users group, or modify DCOM permissions directly to allow your actual account to get remote access. Just assume you are not joined to the local Administrators group in this case. You will have more limited access to monitoring including LM DataSource "Files Services" and Windows Services monitoring not working (without the workaround talked about later). DCOM/RPC Ports Standard remote WMI queries use RPC to connect and RPC uses a mess of ports. First, the Collector would connect to the remote system over TCP 135. The remote system would then pick a high port and ask the Collector to use this new high port for future communications. The high port depends on the OS but current Windows uses ports 49152 thru 65535. If there is a firewall/router between the Collector the remote system and it's not RPC/WMI-aware (being statefull is not enough), you need to open all of those ports between the two. There is a way to modify Windows to limit the IP range but it would be global on that server. WinRM/PSRemote Access A few LogicMonitor DataSources use WinRM (PSRemote) instead of WMI, like the DHCP Server DataSources. This uses the WS-Man (Web Services for Management) protocol on TCP 5985 and 5986 instead of RPC. WinRM has its own set of permissions needed. So to include WinRM in our previous simplified default permissions list: * Remote WinRM/PSRemote: Administrators, Remote Management Users * Remote DCOM: Administrators, Performance Log Users, Distributed COM Users * Remote WMI: Administrators By default Windows only allows those with administrators privileges to access WinRM remotely. If you are a normal user (or UAC makes you into a regular user) you will be blocked by WinRM first before you get to DCOM or WMI. From what I can tell, using WinRM still requires access to WMI and DCOM. I have not experimented with this much. To allow access to WinRM you would add the user to the "Remote Management Users" group. As far as I know, there isn't a management console to control WinRM permissions and the user group is the official method to provide access without having Administrators access. Windows Services Access Monitoring Windows Services as non-admin (or with UAC removing admin) is especially tricky. By Default, recent Windows versions provide the following permissions to look at the Windows Services Controller (simplified for our purposes): * Authenticated users: Query Service Config * Interactive: Service Config + Service Status + Start Services + Read SACL * Service: Service Config + Service Status + Start Services + Read SACL * System: Service Config + Service Status + Start Services + Stop Services + Read SACL * Administrators: All Access * All Application Packages: Query Service Config You can add the following ACL to the existing SDDL string to give a LogicMonitor Service Account read access to most services: '(A;;CCLCRPRC;;;SID_HERE) A = Access Allowed CCLCRPRC = CC: Query Service Config = LC: Query Service Status = RP: Start Services = RC: Read security ACLs SID_HERE = Replace with the SID of the LogicMonitor Service Account I found that RP and RC permissions are required for the WMI request to work Each service can also have its own overriding ACL, so providing access to Windows Services Controller might not be enough. I avoid this workaround if I can. I kinda consider it a limitation of non-admin access and I'm hesitant about playing with per-service ACLs personally. Possible Fixes or Workaround Steps How to fully disable UAC: 1. Run the following single command in PowerShell (run as administrator) then reboot the server New-ItemProperty -Path HKLM:Software\Microsoft\Windows\CurrentVersion\policies\system -Name EnableLUA -PropertyType DWord -Value 0 -Force How to Modify WMI: 1. Computer Management > Services and Applications > WMI Control 2. Right-click and choose properties > Security tab 3. Choose Root then Security button 4. Add the local LogicMonitor service account and check the boxes for Allow Execute Methods and Remote Enable. 5. Click Advanced button > choose the service account > Edit 6. Change Applied to into "This namespace and subnamespaces". 7. Click OK on all the windows. 8. Restart the Windows Management Instrumentation service (and its dependencies). How to gain DCOM Access (suggested method): 1. Add local LogicMonitor service account to the "Performance Log Users" group. Note that adding the user to "Performance Monitor Users" will not provide DCOM access by default. How to gain WinRM Access: 1. Add local LogicMonitor service account to the "Remote Management Users" group.
  8. I'm not clear on what the different is between "Needs No Improvement" and "Not needed"? "Not needed" meaning we would be suggesting to have that item removed? thanks!
  9. Interesting, that is very very new. Cool.
  10. I believe LogicMonitor has build-in ones for AWS and Azure, and I think also Zoom? May have more. It's doable via custom coding but likely not in some generic way since various service have different types and design of status pages. LM's website monitoring is really meant for monitoring a website and verify it's up and working, but not for extracting information from a website.
  11. Something like that, but you would need to remove your old $username, $password and $body lines. Also I noticed that you are attempting to do the comparison to > 1400 directly in the script. I suggest instead you output the value directly like avgQITime=XXXXX then let LogicMonitor check if it's >1400. That would also let you have multiple thresholds for different levels, like for example >1000 is warning, >1400 is critical, etc.
  12. Ok, if you already have the username and password in a device property/token you can use code like this to convert the password to hex (I didn't test this): $Username = '##ddbinfoweb.user##' $PasswordRaw = '##ddbinfoweb.pass##' $Bytes = [System.Text.Encoding]::Unicode.GetBytes($PasswordRaw) $Password = [Convert]::ToBase64String($Bytes) $Body = @{username=$Username;password=$Password} ...
  13. If you are referring to the service account that the LogicMonitor Collector Windows Service is running, then the collector will not know what the password is because Windows doesn't store the real service password itself but some hash of it. This isn't unique to LogicMonitor but services in general. Does the website support NTLM auth? If that is supported then I think you can write it in a way to have powershell pass the hash. But for something like this I would create special device properties like ddbinfoweb.user and ddbinfoweb.pass (you can make up the first part of the name) then have the script use these properties for creds using something like $username = "##ddbinfoweb.user##".
  14. Actually we use that DataSource too and I see the same issue. So I looked at the code and it's just calling the getSharePointSiteUsageDetail (7 day) GraphAPI and retrieving some raw CSV data. The report data looks screwed up to me though. Like all the Site IDs are "00000000-0000-0000-0000-000000000000" and the URLs, Owner Display Name and Owner Principal Name are long HEX codes. I don't have admin to O365 to check directly but I'm wondering if something is broken in the report and how long it's been like that.
  15. As a general troubleshooting test I suggest you look at the DataSource (Office365_Reports_SharepointOnlineSiteUsage) in Settings > LogicModules > DataSources, then use the Test Active Discovery button. Check what it shows for instances there and if the names look correct. If it shows correctly there then I would just delete all the instances then get Active Discovery to rebuild it. Note that this will cause you to lose any historical data for sharepoint site usage, but since it sounds like it never worked until just now, so I assume that is ok to do. If the test still shows GUIDs then you might need to dig into the powershell code or work with LM support if it's not by design.
  16. I'm not sure about this exact issue but looking at the Microsoft_SQLServer_Troubleshooter DataSource code, LM checks for sysadmin access by using the below SQL statement and checking if userstatus = 1 (basically). Perhaps logicmonitor.svc is part of a group that is sysadmin? SELECT IS_SRVROLEMEMBER('sysadmin', SYSTEM_USER) as userstatus
  17. Since you have collectors per site, you can just run a Resource Inventory Report and include the "system.collectordesc" and/or "system.collectorid" properties. Then sort/group by the collector.
  18. One the server itself it's at c:\Program Files\LogicMonitor\Agent\logs\ (by default) but you can also grab the logs from the portal.
  19. Interesting. And it's checks for the collector itself? I would check the EventLog for crashes or other messages, along with the Collector log files. I would also check for any antivirus or security software that might be causing problems. Make sure that nothing it stopping PowerShell from running or killing it since the collector might use PowerShell for some wmi queries. Can you query Uptime and CPU on the server directly using WBEMTEST or get-wmiobject?
  20. Can you provide some example code? They fact that your getting html response instead of JSON likely means something more fundamental is an issue then the specific EventSource API details. You might want to use some of the REST v1 examples on the support pages, to make sure any API calls work, then you can convert them to v2 convention. Based on the v2 docs, it does look like import via XML is the documented method to create EventSources. You might need to generate the XML file (perhaps by having an XML template that the script modifies) to provide into the API call.
  21. As far as I know parent tokens are still not available. One workaround is to use dynamic groups. Under each Customer you can create a dynamic group for each site (something like system.staticgroups =~ "^Customer A/SiteB/") then point the widget there.
  22. Also feel free to also reach out to me about this. I've brought up this issue several times over the past 4 years including several tickets: tickets 76322, 88632, 108961, FEED-2277.
  23. Unfortunately Datapoints must be valid numbers and strings can't be use. The two periods makes it an invalid number. Generally you can store version data as property data (strings allowed) or you can perhaps change the DataSource to crop the version or drop the 2nd period, for example 4.4 or 4.45 .
  24. IPs also need to be unique per collector/ABCG also and I don't think one CSV file itself can specify which collector to use (I don't use CSV much). Might need to do one CSV import per customer so you can chose the correct collectors. For an MSPs I suggest investing in writing onboarding scripts. But I definitionally agree on the error messages and more error checking. CSV importing can allow items to be imported that have problems that GUI would normally prevent like newlines and ending spaces in names.
  25. MSPs have collectors installed on various customer's sites. Collectors also act as a dependency so if a site goes down and takes the collectors down too, you don't get all the devices at that site to send tons of alert notifications. Remote Access via collector proxy might help gain access if site-to-site connection is down.