Jump to content

tlphipps

Members
  • Content Count

    264
  • Joined

  • Last visited

  • Days Won

    10

tlphipps last won the day on March 27

tlphipps had the most liked content!

Community Reputation

22 Excellent

1 Follower

My Information

  • Location
    Dallas, TX
  • Agent Count
    3000+

Recent Profile Visitors

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

  1. Thanks. We actually have done that and have very decent performance from our /automate site. I just mentioned that we didn't notice it being any better/different really with the changes from this plugin as a point of reference.
  2. I actually had the same problem. It was weird. It apparently ran the first time successfully enough to create the stored procedure. But subsequent runs errored out and when I ran the query manually in sqlyog it said it failed since the SP already existed. I kinda assumed it was just my older version of MariaDB. So I just manually ran the second query and things seem to be working well for me. Definitely noticed a performance boost for thick client operations. Not really anything for web client.
  3. Just got this installed and running. I didn't actually 'enable' the plugin before running the script so it failed to run the second query. I figured it out and got it sorted and running but just thought I'd mention it.
  4. We just have an 'old agents' groups with the following expression. When an agent has been offline more than 180 days in CWC, we just 'end/delete' the session. GuestConnectedCount = 0 AND LastConnectedEventTime < $180DAYSAGO
  5. no, it leaves the session orphaned on the CWC side. "ending" the session on CWC side would require tapping the API and doing stuff I'm not directly familiar with. With over 6,400 active agents, we ALWAYS have orphaned sessions so we do periodic cleanups based on last connected date.
  6. Thanks so much for sharing this. While your instructions don't explicitly say this, I think it's wise to shutdown IIS and the LTDBAgent services to essentially stop Automate services and traffic while working on the database like this. Sadly when I gave this a shot last night I got stuck. After running the mysql_upgrade, I wasn't seeing any authentication errors but quickly found I couldn't continue since every time I logged in with my root user account, I was given an error saying I needed to update the password with the ALTER USER command. Unfortunately doing that just resulted in an error about a wrong row count in the mysql.users table. And all my research on that issue pointed me to just running mysql_upgrade again. But not matter how many times I did that, I was stuck. I finally just reverted back to MariaDB (which was easy given this upgrade method!!). Any ideas how to overcome or avoid this user auth issue? Should I maybe have tried running the user table cleanup commands while I had my first session open maybe BEFORE the mysql_upgrade command?
  7. Yes we use it now. But the O365 ProPlus installer (click to run) now also has an option to remove previous installs (haven't tested that). From my limited testing, when doing a click to run install, it replaces any existing click to run versions of office automatically. So we don't specifically doing any uninstalling for those proactively. But the 'windows store app' stuff is still there. I've never tried to script removing that built-in stuff.
  8. We’ve incorporated stuff from here in some cwa scripts. https://github.com/OfficeDev/Office-IT-Pro-Deployment-Scripts/tree/master/Office-ProPlus-Deployment/Remove-PreviousOfficeInstalls
  9. @kevinjackson Sorry for never responding. I didn't get a notification email and just logged back in today. The URL for your transfer folder is: https://<your_cwa_fqdn>/labtech/transfer/xxxxxxxxxxxxxxxxxxx
  10. Been running patch 9 since Tuesday evening. All good so far.
  11. We have a script we put together for this. We built the core of it in powershell and then just use the "Script Execute" command in a CW Automate script to run our powershell. Here's what we're using: # Get list of accounts in local administrators group that are NOT allowed (this filters the allowed accounts) # We have to leave 'administrator' as it's a built-in account. But we disable the account via ThirdWall. $remove = net localgroup administrators | select -skip 6 | ? {$_ -and $_ -notmatch 'successfully|^administrator|^msp.localadmin|^xyz.devadmin$'} # remove the accounts foreach ($user in $remove) { net localgroup administrators $user /delete } We then just have this script scheduled to run against all machines at this client periodically (every 3-4 days I think).
  12. I want to publicly thank both @dfleisch and @herrchin for their engagement in this thread and conversation. It's totally OK to disagree and have different thoughts/approaches to things. As a long-time CW partner (Labtech user since 2011), I agree fully with @herrchin's suggestions and well-reasoned responses. I appreciate @dfleisch sharing the 'how we got here' information but, honestly, I think it's more telling of the failures on the CW side in properly setting standards and expectations for partners. I want to be VERY clear, that's not a jab or knock toward @dfleisch. It's a comment on CW, the company's, approach. @herrchin does a great job here explaining our (partner) frustrations with the approach CW has taken on this and while it's great they came up with some benchmarks, I think it's clear from comments by both parties that the benchmarks being used aren't actually correct for the real-life workloads seen on CW Automate servers. So to steal @herrchin's example, CW is asking us to measure apples where oranges are what's needed. That's definitely doing a disservice to those partners (current and future) who are using or looking at using Azure or other services that have 'scored badly' on the apples test. Not that anyone cares at this point, but I'll reiterate that we're happily running Automate in Azure on a single VM (8 CPU, 56GB RAM) with over 5,300 agents. And I'm about to grow that to close to 6,000 agents before the year is out. I've contemplated splitting our server roles, but to be honest, everyone that looks at our instance performance (including employees coming from other Automate shops) is blown away at the performance we have (compared to Automate in general.....we still hit the usual Automate slowdown points). Yes, it's an expensive VM. But it's how we've chosen to structure our business. It's working well for us. And it's performing awesomely. Even when paging to disk, etc. we see NO slowdown due to disk i/o. But our 'apples score' using the current diskspd recommendations is abysmal. I truly hope some CW product managers see and engage with the information from this thread. Especially the points/info raised in @herrchin's last post. THAT is how CW can improve the product and their partner satisfaction and confidence level.
  13. We don’t do this universally at this point but we certainly have it in place for our clients with no onsite servers. Doesn’t really need much horsepower. Most of ours are retired desktops or laptops from our internal uses. There’s no need or requirement for probes being on DCs.
  14. Whoops! Definitely didn't mean to post up here with our CWC Identifier in there. Thanks @mike_judd for the head's up on that. I've replaced the XML above with a generic version. I went ahead and added a 'variable set' line where you can easily add your specific CWC Identifier in each section of the script.
  15. I'm guilty of grabbing @DarrenWhite99's scripts previously and modifying and using them but never posting back. First off, Darren, YES these work on macOS quite well (or did back then). One thing we discovered recently was that the program directory on macOS was changed during a a mid-6.9 release of CW Control. So we updated our "Get GUID" script to properly grab the GUID from the old location AND the new location. This has been working well for us. Here's our updated "Get GUID" script. Technically is still supports Windows, but due to the plugin handling that directly now, we really only use this for macOS clients. We just call this script at the end of our "install" script on macOS machines to update the CWA database so the link from CWA to CWC exists for Mac agents just like it does for Windows agents. CW Control Get GUID - CUSTOM.xml
×
×
  • Create New...