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

1055 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-WmiO
  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
  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
  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
  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 sendin
  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
×
×
  • Create New...