Jump to content

dpltadmin

Members
  • Content Count

    26
  • Joined

  • Last visited

  • Days Won

    5

dpltadmin last won the day on December 30 2019

dpltadmin had the most liked content!

Community Reputation

8 Neutral

My Information

  • Location
    CA.Modesto
  • Agent Count
    4000 - 6000 Agents

Recent Profile Visitors

940 profile views
  1. As the release notes suggest. I can confirm this issue is resolved in 2020.2
  2. Thanks for this. I had been looking for a solution to this for some time as I also have a client with a single label domain name and there are other times when i want to filter based on whether a machine truly belongs to a domain vs workgroup. I started to go down the route of an EDF/Remote Monitor/Script Combination doing the following: Computer Level EDF / Text / #DomainMember Remote Monitor External EXE Check "%WINDIR%\System32\WindowsPowerShell\v1.0\powershell.exe" -nologo -noprofile -Command "$EDFValue = '{%^e:#DomainMember^%}'; $W32_ComputerSystem = Get-WmiObject win32_computersystem; $PartOfDomain = $W32_ComputerSystem.PartOfDomain; IF ($EDFValue -contains $PartOfDomain) {Write-host $PartOfDomain "`(ValueCurrent`)"} ELSE {Write-host $PartOfDomain} Condition: Contains ValueCurrent Script to call when the Remote Monitor results didn't contain "ValueCurrent" The returned result contains an extra space and CR/LF so that is why there are lines for removing them before placing the data into the EDF otherwise when powershell compares the EDF Value with the result of the command it doesn't behave as expected The first time the monitor runs it should fail because the EDF Value is blank (assuming you've sent Update Config to your agent first) and thus @RESULT@ would be either true or false. Since that doesn't contain ValueCurrent the script runs in the Then statement. The next time the monitor runs it would report either "True (ValueCurrent)" or "False (ValueCurrent)" This way directly from the monitor you can tell if the value was True (Domain Joined)/False (Workgroup) and if it matched the current EDF Value. If the computers domain membership status ever changed the monitor would pick up on this and update the EDF Value. What I don't particularly like about this approach is that i had some computers return things like: ExeMonitorMissing (Assumed Powershell Not Installed/Missing, I haven't dug into it further) Get-WmiObject: (Not sure why it stops here, also same result when I previously was using the alias gwmi) Get-WmiObject: invalidclass"win32_computerystem" (Online research led me down paths for troubleshooting WMI) Theshellcannotbestarted.Afailureoccurredduringinitialization: (Something about powershell broken?) Which basically just means I have to fix more stuff for to be able to 100% rely on the results. However its probably 99% correct in the system so not bad. The other method i tried out after the above method was just using the command you provided with Role Detection I basically setup 2 new Roles using {%@for /f "usebackq delims== tokens=2" %x in (`wmic computersystem get partofdomain /value ^| find "="`) do @ECHO %x@%} #Domain Member Detection Result Contains True Applicable OS = Windows #Workgroup Member Detection Result Contains False Applicable OS = Windows Example: I imagine computers with WMI problems also will be missing from the Role Detection so depending on how prevalent that is I'll have to look at what it takes to remedy those situations. Outside of that the obvious issue I see is a computer could have both roles detected at some point if its status were to change, however, it really shouldn't matter much depending on what I was doing with either role. Either way this is where I have @DarrenWhite99 's Expired Role Detection Monitor setup to cleanup Roles that have not been detected in the last 7 days so this shouldn't really be an issue for more than a week (and I could adjust the amount of days if i needed to shorten it). Anyhow, I shared with the hopes that someone else finds this useful and maybe has ways to improve on it or has better methods they can share. Thanks again @mcmcghee 🍻
  3. I just upgraded my plugin from 1.0.0.2 (eek!) to 1.0.0.20 and I don't remember what version it was on in CWC but I would have regularly updated it randomly every few months and it was already on 1.0.0.27. Anyhow, after the upgrade I was having the same issue as @drobert88. Invalid token. I did all the normal stuff, reloading dbagent, reloading control center, checking updated RMM+ Passwords config options, restarted CWC Services, checked plugin file version in my local plugin cache. Everything checked out so then I went searching the interwebs and landed here. We've always been an on-prem setup. I checked the config table and mine was set to localhost for whatever reason. Updated it to my Automate URL and it started working. Thanks and the updates to the plugin are amazing! Thank yo so much @bigdessert
  4. Setup: Server A - CWA v2019.11 / Server B - CWC v19.4.25666.7235 (Latest Elidgible) Chat Session turned into Ticket 12585906. Support collected logs and sent straight to Tier 3. Update: Known Issue Ticket 12603474 - Fix appears to be targeting 2020.2 Issue: Support Session Viewer in web (web only now anyways) not loading for users, blank white page. Support Session Viewer only works for Super Admins. If tried with a user that is not a Super Admin and then trying with a Super Admin without clearing cache or using Incognito mode, the Super Admin user will appear to also not work so testing Super Admin account would need to be done with Incognito window. Looked at by Connor Ward and one of his colleagues. Support believes that this is a permissions bug. Additional Notes: Requested Support Sessions do show up in CWC Web Support Sessions and can connect to them without issue. On the Support Sessions Viewer page when its a blank white page, F12 / Console will read: Failed to load resource: the server /cwa/api/v1/ExtensionActions/Control/SessionViewer:1 responded with a status of 403 (Forbidden) @bigdog09 Ticket status with Connectwise Support has changed to a status of "Known Issue" I don't see anything published in the University Known Issues yet but it just received the status change this morning.
  5. Thanks for this both servers I've had to fix were version 190.110
  6. Per Support: Bug Introduced in v12p12. Issue still appearing in 2019.2 (We are on v12p12) Known Issue Ticket# 11289491 (Not sure if public facing yet per support chat) Password Changes for User Accounts that are not in the Super Admin User Class, after password change, can log into /automate (AWA), however, the user loses the ability to log into Control Center Thick Client or WCC. Workaround (Verified Working in my Case): Assign "Super Admin" User Class to the User Reload dbagent Verify User can log into CC/WCC Remove "Super Admin" User Class from the User Reload dbagent Verify User can log into CC/WCC without 'Super Admin' User Class Chat Session Highlights:
  7. I'm having very similar symptoms. v11p19.471 / Agent Count ~6100 I am aware of WindowsUpdateETLFiles table issue and I regularly truncate it. IIS gets flooded/backed up, control center stalls/locks up (Except from the server itself). IISRESET usually does the trick, but sometimes i need to bounce the server. Initially i worked with support and the best they could come up with was their tool that upped our Max Connections to 3 * Agent Count, which is now set at 18123. When that didn't solve the problem they are basically telling me that the high spike times are Agents sending in windows update data and that the processing of said data is better in v12p04 and that i need to go to that to resolve the issue, however we are not ready to move to v12 just yet and deep down i don't feel like that's the cause, especially considering it happens at times when the Agents aren't scheduled to collect and send that data in. On the same day support upped our Max Connections and I realized that didn't help,, I upped us from 8 CPU Cores, to 12, which didn't help, then i went to 16 CPU Cores, and things were great for about 2 weeks. Then the issue started happening again. I feel like adding some more power resolved one issue, and then another one has risen up that is similar in symptoms but a different root cause (which could have also been there all along). When it starts to drag Eventlogs on the server start showing ASP.NET 4.0.30319.0 Warnings with timeouts suggesting it may have occurred because all pooled connections were in use and max pool size was reached. Disk Queue Length is good SHOW FULL PROCESSLIST my database isn't flooded with SHOW VARIABLE, and generally only has a handful of tasks happening. Today, based on @Jacobsa recommendation above, I've set my application pool for labtech to recycle every 60 minutes instead of the default 29 hours and changed my Event Log History from 3 days to 1 day. I've also added the property GroupPatching30Minutes=false (This property didn't exist previously) I feel pretty good about the above changes, my gut keeps telling me IIS is the problem but I'm not sure what changes to make. Hopefully recycling every hour will keep the issue from reoccurring. Only time will tell at this point. My next 2 steps are setting Max connections back down to 3000 and changing Max connect Errors to something larger than 100 but i feel less excited about those changes having any affect. Depending on the outcome probably dial back the CPU cores until i can find a happy medium. For now when the issue occurs its just IIS really, everything else about the server runs well and appears stable. Ill post an update when I have something to report. EDIT: @Jacobsa Your suggestion made the single biggest performance improvement to the stability of our CWA Environment since its original deployment (26 months ago now). I no longer have to randomly go in and reset IIS or reboot the server to get it to behave again (which always seemingly worked for random periods of time, sometimes it was good for hours or sometimes it was only good for 20 minutes). I did originally set the pool to recycle every 60 minutes, and a few hours later dropped it down to 30. maybe 2 weeks later I dropped it down to 20 minutes and that's where I've been most stable. I've now run my server for 60+ days of uptime after making the change and only had to reboot for pending updates. Techs are much happier with its stability and "Is Labtech Down?" is no longer a running joke in the office. I owe you a couple drinks if we ever link up somewhere. Thank you so much for the suggestion.
  8. Maybe it was just a fluke for me that it happened to come back after I created a new client. It was annoying and I was trying any way I could without closing CC. Its on my dev server that doesn't have a lot going on, but I can for sure confirm I have experienced the issue of items disappearing from view in that area of the interface.
  9. I noticed something similar yesterday where I was browsing the client tree and all the clients disappeared. Adding a new client forced the tree to refresh and redisplay the clients that had disappeared from view.
    v2.1 is vastly improved over the original version. Much quicker and more accurate. Thank you @DarrenWhite99
  10. If it was, I don't recall experiencing that. On my dev server I went from v11p19 -> v12p01 -> v12p04. When I did the upgrades, my server wasn't pending a reboot.
  11. For Patch 5, I pushed an issue up to dev which has now been determined as a Known issue, however, it is not listed on the known issues page yet. My Ticket: KNOWN ISSUE: Ticket #10149848 regarding " Upgrading v12P04 to v12P05, Installer Stuck on rewrite_amd65.msi /qn /norestart(10120711) If you already have URL Rewrite Installed on your IIS, then you will not experience the below issue: Basically when running the Patch 5 update, if you don't have URL Rewrite installed for IIS, the patch attempts to do this for you but appears to use the wrong MSI flags for quiet, norestart, so in the middle of installing the patch you will get an MSI Help Popup and the patching will not continue until you click on ok of this window. There is another step in the patching process where you will get the same pop up. Clicking through both of these MSI Help popups the upgrade seems to complete properly with the exception of the new Web Control Center, it won't install/display if IIS doesn't have URL Rewrite Installed. Minor issue but thought I would share with the community. Edit:
×
×
  • Create New...