Jump to content

KI_EricS

Members
  • Content Count

    28
  • Joined

  • Last visited

  • Days Won

    1

KI_EricS last won the day on November 29 2018

KI_EricS had the most liked content!

Community Reputation

1 Neutral

My Information

  • Agent Count
    4000 - 6000 Agents

Recent Profile Visitors

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

  1. @Matthew Mclaughlin, I recommend you review the ConnectWise Automate Knowledge Base Articles if you haven't already. You could definitely use @danialbulloch's script as a basis here, but I recommend either manually (or by running a script) downloading the needed ISOs from Microsoft.com to a server or a hard-lined, always-on PC running a Windows Pro edition client OS. What you do from there is dependent upon your environment ("all Workgroup", "all AD Domain", or "mixed")... If "all Workgroup", then either set it up proper as per Microsoft documentation if not, or get migrated to a proper AD Domain. If "mixed", get migrated to a proper AD Domain. Hard-line the target PCs. ...and LT/CWA configuration. If you're running a single Location in that LT Client, then set the hosting PC/server to be a "Master" in LT. If running multiple Locations in that LT Client, then consider setting FastTalk to go by Router/Public IP Address instead of by LT Location (remember: system-wide setting). Consider using "caching". (See: Agent: Caching 101 | Adding, Modifying, and Removing Locations | Troubleshooting Caching ) Set the run of the deploy script to "stagger" at least 10 minutes (if not 30) and I recommend running the first time as "once" only. The biggest gotcha here, and possibly your main problem, is a quirk (pain) on (only, I think) the Windows-side involving how certain operations are performed. It has been my experience that some operations -especially if they use elevation- require that a functioning User Profile exist on the PC for the user account being used/authenticated against. I have run into this when using PowerShell in LT Scripts, specifically when using "by-pass" and "as admin" options/functions. Other possibilities involve the PC's Environment Variables settings causing the LT Agent issues, and the LT Agent being unable to login as a user.
  2. @Matthew Mclaughlin, you might this newer thread by @danialbulloch useful: Windows 10 Build Upgrade - 1803 Is Going End of Life!
  3. @Cabraghman 's fix can also be accomplished by directly editing the related LT database table and changing the AV ID for the trouble-some security application(s) to append them to the end of the table. Problem is updating the system (and/or related plugin) will probably undo the fix. @DarrenWhite99, that is very interesting... I wasn't aware of the additional processing involving the state of the detected security app installations. That probably explains some things that we've encountered this year. Best over-all solution to this would be to divorce the identity the record (ID#, UID, whatever) from defining priority/preference for any given security app's table entry. Also, consider this when initially encountering AV identification issues for an Agent: Automate Not Detecting Antivirus
  4. I was originally "Wait. Wot?" when I saw this thread because I've seen the setting in the Dashboard. Then I pulled the related documentation and... yeah. Including the linkage and relevent quote for reference by others: ConnectWise Automate Documentation > Administration and Configuration > SSO Setup for Automate [Emphasis added]
  5. ConnectWise Control Used As Entry Point In Texas Ransomware Attack I would image that many, if not most, of the users of this site have heard of the increasing trend of MSPs being targeted by threat actors to distribute malware (sp. ransomware). That article (posted: September 17, 2019, 01:25 PM EDT) is of special note because of this statement: [Emphasis added] It also includes, and references, quotes by John Ford, CISO of ConnectWise, which seems to confirm that action by ConnectWise: The article does not state when that decision was made/announced or link to a formal, written announcement by ConnectWise. So far I have failed to locate anything "official" from ConnectWise regarding this, but openly acknowledge the very real likelihood that I have just failed to find it. Has anyone seen such an announcement by, or received an email from, ConnectWise regarding this?
  6. We updated from 2019.3 to 2019.5 this past weekend. What happened: What was learned: Possible network performance/stability issues aside, LT Support identified the LT -side problem as being caused by User Permissions issues. Apparently, there were quite a few security-related changes made in 2019.4 and/or 2019.5 which were involved here. LT used to "tolerate" what I've called "ugly permissions": multiple User Classes assigned, sometimes with over-lapping Permissions and even including 'Super Admin' thrown in. Used to be you'd have performance issues due to LT having to sort that mess out. Now LT will kick a user to the curb. The biggie was having more than one User Class assigned that has the 'Super Admin' Permission, though I wouldn't rule out other Permissions as possible causes of either logon issues, or Control Center performance or functional issues.
  7. Is there a minimum required (or recommended) version of ScreenConnect/Control (Server/Access Agent) and/or the related LabTech/Automate Plugin in order to use the "Use Control to Update your Automate Remote Agents" Utility? Also, does ConnectWise have that utility "published" any where on their website? (Didn't see such a link in that Announcement.)
  8. @imurphyHow does your solution handle situations where the font is already present? Are you doing anything else in your LT Script to handle that? Also, please see my recent post in a similar topic.
  9. Not exactly from what I've seen while working on a similar task myself. Apparently there is a Windows Registry item that needs to be created along with each font (not font family) installed to actually register the font with the system. Here are two (external) sites that I'm currently referencing for my work: How to: Deploy New Fonts via GPO Pushing Fonts via GPO I'm leaning towards adapting this PowerShell script to being run from a LT Script.
  10. I've often wondered about how well that'd work, if at all... I have questioned LT Support within the last few months about the Share and/or NTFS file permissions that are needed for LTShare and the FileService to function properly. And they insisted those permissions (both types) need to be set to "Everyone" ("Full Control") for it all to function as intended. Needless to say, I have a fundamental problem with that being necessary. We were told by LT Consulting after FileService was deployed that the only users who might actually need to have LTShare mapped on their workstations are those who are doing system administration/development work such as writing scripts, reports, etc. (I have not tested that myself yet.) Manual human access of LTShare aside, what are the minimum permissions needed for the FileService, a local installation of the Control Center ("thick client"), LT Agents, Web Control Center, etc, and which system entities (by default) need any access whatsoever to LTShare? On a somewhat related note... Can we hide the LTShare network share without it hosing LT?
  11. @bmillerWhat is the configuration of that Alert Template? Also, is this related to a plugin, or is it purely custom work?
  12. I believe that is either set, or influenced by settings, on the Dashboard. One thing though, you need to check if there are any restrictions/limitations that will be imposed by any other applications you have integrated with LT.
  13. That sounds like some of the issues we've been experiencing as of late (Version 12 Patch 10; 4600+ Agents; Split Server). That's been attributed to an issue with the new(er/ish?) CWA File Service. Definitely need to check the permissions (share+NTFS) on your LTShare. I personally did not like having to do it, but I did have to. as per Support, grant 'Everyone' "full access" share permissions and open up the NTFS permissions likewise. I do not blame LT/CWA Support for having to do that, however I do blame Dev for apparently leaving us to have to use such loose permissions. We've been having other issues with v10 too and are looking into updating to v12 as several of those issues are supposedly resolved by that patch.
  14. @SparkerThe first (oldest) reply/comment might be of interest to you.
  15. I didn't find this here earlier and ended up contacting Support about it, but props to @svc_root for posting a solution for this issue first. However, allow me to elaborate on this matter... Affects: LabTech/Automate Control Center version 12 patches 9 and 10 Possible Symptoms: Users unable to log into the Control Center. Users already logged into the 'Control Center may suddenly begin experiencing "never-ending" refreshes of data and/or will be unable to effectively interact with the application. The Control Center may suddenly "crash"/exit/quit. Issues occur during certain time frames, usually reoccurring and possibly multiple times of day. Users across multiple time zones may experience issues during time frames that will resolve to the same UTC times. May not affect all users in a given time zone, or any users in a specific time zone. For us a confirmed "dead time" resolved back to 1700 to 1900 hours (CST, UTC-6) every day, with another reported time frame ending at 0700 hours (CST, UTC-6) at least on week days. [There are also messages in two logs (one client-side, one server-side) that will correlate and basically confirm the problem. Will edit in that info soon-ish.] Here's what LT Support had me do to resolve: What didn't get mentioned there was that restarting the LT Database Agent is needed to effect that change.
×
×
  • Create New...