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.]]

dpltadmin last won the day on December 2

dpltadmin had the most liked content!

Community Reputation

6 Neutral

My Information

  • Location
  • Agent Count
    4000 - 6000 Agents

Recent Profile Visitors

733 profile views
  1. 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 (Not listed in Known Issue Tickets at this time) 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) I'll update further when I have more information. @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.
  2. Thanks for this both servers I've had to fix were version 190.110
  3. 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:
  4. 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.
  5. 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.
  6. 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
  7. 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.
  8. 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:
  9. My apologies, when I made that post I had forgotten that the feature was added because I was looking at the plugin in my production environment. This actually is what I was looking for, although in my production environment I am using an old version ( of the plugin where this feature wasn't in there yet. In my dev environment ( it does have that option. I just need get my production environment updated to the latest version of the plugin. I think I was holding off on my production environment because if I remember correctly the older version of the plugin handled the service account for workgroup only computers fine and in a newer version that broke and you hadn't revisited resolving that issue yet unless I misunderstood that issue. Edit: Oh yeah, I just checked on my dev environment and even with 0 for symbols, the generated password still has dashes and dollar signs in there.
  10. Would be really cool if this had an option to prevent special characters from being generated in the random password.
  • Create New...