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

JosefNT last won the day on January 31

JosefNT had the most liked content!

Community Reputation

2 Neutral

My Information

  • Location
    Monroe, LA, US
  • Agent Count
    3000 - 4000 Agents

Recent Profile Visitors

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

  1. Just throwing this out there ... What about tying in something like WinAuth? https://winauth.github.io/winauth/ Open-source, portable authenticator app that takes a key (or reads a QR code you load into it) and runs the same as a mobile-device authenticator app. I'm not sure about command-line usage, but I've been thinking about playing around with it to allow me to enable 2FA on my Automate service account (special user account I set up for running jobs on our app server). You can set WinAuth to run on startup and even create global keyboard shortcuts for pasting specific tokens on the fly. Folks at my office take screenshots of their QR codes when setting up any new 2FA and use the same code for their phone app and for WinAuth, so they can generate identical tokens either way. Might be useful if there's a way to tie them together.
  2. I have to say that RMM+ Password Link is all of our technicians' favorite plugin by a long shot. They were all excited when I applied the most recent update and announced that I was turning on the feature to send an Enter keystroke after the password. However, in all my testing, this feature has yet to work for myself or any of our staff. I have noticed that the checkbox to enable the extra keystroke is not retaining its checkmark after I click save and then reopen it. I took a look at the plugin's tables in the database, and there I can see columns for all of the other options, but I don't see anything that looks like it would be related to that feature. Is it possible that I just need to remove and re-add the plugin? Any known issues with that functionality? I'm happy to share any screenshots or details about our environment if it helps, but I thought I'd ask about it first to see if there is something obvious I'm missing. Great job on the plugin though! It has quickly become an indispensable part of our technicians' workflow.
  3. Thanks @Duvak! Yes, most of our clients on MSP contract have AD environments, so running probes as a local account is SOP in most cases. I was just a bit confused about the differences between Passwords to Attempt fields in Deployment Manager vs. Network Device > Access Password vs. Probe Settings. I was able to successfully deploy the agent to the servers for this particular client, then simply disable Auto Deployment to prevent pushing to workstations. I just wish there was a red asterisk (or some other visual indicator) next to fields whose functionality was altered with a recent Automate update or which were deprecated and no longer serve any purpose.
  4. I missed that too! That seems to answer my question of how to disable auto-deploy without disabling deployment altogether. But I would still like to find out what the other credential selection fields are for. It would be handy if there was an indication of updated documentation when viewing different agent screens (different color help icon maybe?). Something to reflect "hey, the functionality here has changed". With all of the changes coming through so many facets of the program (in both thick client and WCC), it's hard to look at a changelog before an update and remember all of the inclusions three or four weeks later.
  5. I just discovered this thread while searching for: "agent readiness check" failed credentials This failure surfaced when I enabled the probe on a new client's domain controller. We are only monitoring their servers, so I don't want to push agents to all workstations. I ran the discovery scan to see what other servers they had in their network, thinking I would manually send agent deployment commands to the discovered servers without ever needing to enable "automatic deployment". However, despite applying the password at various levels (updating config and testing between each change), my readiness checks kept failing, reporting "no valid credentials" as the cause. Variations I tested (all failed): Saved the domain admin credentials at the client level, and set them as the default for deployment at the location level (along with service plan selection, etc.) Opened each target Network Device within the thick client, set the Access Password in the Identification pane and saved Opened the Deployment Manager in the thick client and added the credential to the passwords-to-attempt pane on the right, and saved When I found this thread, Adam's explanation revealed the real problem: After checking the box on the probe settings to Enable Remote Agent Deployment, it allowed me to move the Domain Admin credential into the Passwords To Attempt list, and subsequent readiness checks on servers passed and allowed agent deployments. I have noticed, though, that unchecking the Enable Remote Agent Deployment checkbox removes the credential from the right pane and places it back into the left, Stored Passwords pane. This raises a few questions: What use are the various password selection fields moving forward? Are these fields deprecated and no longer applicable to any functionality: Network Device Access Password Deployment Manager passwords to attempt What's the difference between "Enable Remote Agent Deployment" on the probe and "auto-deployment" as I previously understood that checkbox to represent? If I leave that box checked to allow me to manually issue agent deployment commands on network devices, is it going to attempt workstation installs during the next scan? Do I have to manually toggle that checkbox to enable specific deployments while still preventing workstation auto-deploys, or Is there a setting somewhere in the new WCC or thick client probe settings that would allow me to enable deployment but only do so manually (i.e., disable automatic agent push without disabling agent push altogether)? Not urgent, as I have deployed what I need now, but I would like to get a better grasp of the credential fields requirements and agent deployment functionality moving forward.
  6. I can confirm the behaviors @avdlaan describes: scans/re-detections don't actually seem to be running when I attempt to trigger them manually, and my Probe Commands window remains empty even after attempting to initiate a scan or re-detection. Following the steps outlined here for upgrading from Gen1 to Gen2, I purged network devices from a probe for a selected client, then deactivated the Gen1 probe. When I re-activated and went through the Gen2 wizard, the probe functionality returned, but none of the options to perform manual actions appear to be working, and the Probe Commands window is empty. I have tried initiating a rescan via the "Play" button on the Device Discovery pane in the Overview screen and also tried via Commands > Probe > Initiate Network Scan and Commands > Probe > Run Device Detection. I also ensured the probe scan settings were set to have Only run discovery in scan window = UNCHECKED. I want to make sure I'm not missing something regarding manually initiating scans/re-detections, as well as the Probe Commands window appearing blank. Finally, I am interested in finding out what benefit we gain from activating the MAC Address Scanning feature? I have seen the documentation reviewing how it fits into discovery as the optional third step. But I haven't been able to determine what that third step of scanning the MAC addresses actually accomplishes. Is it enabling some new functionality? Does it allow more reliable agent push to detected devices? We face multiple client probes (Gen1 and Gen2) in which devices are mis-detected (Windows desktops appearing as "Manufacturer = Roku" or "Manufacturer = Apple, Inc.") or simply not allowing agent install (multiple VM servers at one client, for instance). If enabling MAC address scanning will remedy one or more of these situations, that's a strong argument for turning it on. If it is intended to perform some other function ... what might that be?
  7. @Wade , if you (or any other users arriving at this thread) are still looking for this functionality, try this: Enable the Legacy menu as noted by @RDeBok (if needed) In Control Center select System > Configuration > Dashboard, then go to Config tab > Control Center subtab, and check the Legacy menu checkbox at the bottom Add a Property within the Dashboard In Dashboard go to Config tab > Configurations subtab > Properties subtab Name: DataViewCreator Value: True Click Add Click Force DBAgent to Reload Properties Close and re-open Control Center (Reload System Cache did not work in my case) Legacy menu should now expose Dataview Creator item. Profit.
  8. Fantastic addition to our onboarding process! I can confirm the initial run completion delay. We have 4100+ agents in Automate, and I've been sitting with a PowerShell ISE cursor blinking for around 35 minutes so far. Based on the ComputerID it's stopped on (4197), it seems to be almost complete, but after reading the previous comments I'm hesitant to Ctrl+Break it for fear of missing any queued IDs. I see that the assorted functions within the script query to only return devices in which the warranty fields are empty, so I'm assuming that if I must break and re-run the script locally it will only attempt to process machines missed by the first run. If there's any reason I shouldn't re-run it locally to catch any stragglers, please let me know. Great work, and the installation instructions were spot-on!
  • Create New...