Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

1 Follower

My Information

  • Agent Count
    750 - 1000 Agents

Recent Profile Visitors

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

  1. Sadly in our instance only packets downloaded on the computer to install to directly while signed into automate contain the correct FQDN ... This will now be clarified and corrected with the connectwise support in the following weeks hopefully. Even packages downloaded on one computer, where it showed the correct FQDN and then copied lose the FQDN while copying or whatever. Very funny error but gladly evadable by the Serveraddress parameter. I have included the branch into our startup scripts that are deployed via GPO and so far it looks good. I've also tested it on a few machines without errors and online state now showing up correctly. Thanks for your patience and have a great weekend
  2. Just found the solution! If you do the conversion from registry value to Time with Get-Date instead of System.DateTime it uses the local timeformat for both and this works. I just replaced ((( (Get-Date) - [System.DateTime](Get-ItemProperty "HKLM:\SOFTWARE\LabTech\Service").LastSuccessStatus).TotalSeconds) -lt 600) with ((Get-Date) - (Get-Date (Get-ItemProperty "HKLM:\SOFTWARE\LabTech\Service").LastSuccessStatus) -lt 600) and now the online check works just fine. Please check if this is also true for the US culture and if so, would be great if you could update the module. The server address parameter for msiexec also would be a welcomed addition to circumvent the msi package errors. Thanks for all the help and time guys!
  3. The problem is the conversion. Powershell won't convert the registry key to System.DateTime for the substraction. System.DateTime expects a date in the US format, thats why it fails. Because it tried to read 29.05.2020 as US time and since there is no month 29 it failed. If I manually enter a string for the conversion I get the following results: This explains why the conversion failed last week for me. But even now this still produces wrong values.
  4. Yeah that seems to be the problem. But this should fit the german time format System.DateTime tries to compare to so I dont understand why it cant convert ... Heres the output: At the moment I've cloned your module in our cloud storage and just set $Online = $ True to ignore the check completely and I had to change the msiexec to hand the server address to the installation manually like stated above: I found a solution for the Date Problem! Conversion with this post worked fine. Converted like this the Date has the same format as the registry entry and should be comparable: $cultures = “de-DE” foreach ($c in $cultures) { $culture = New-Object system.globalization.cultureinfo($c) $date = get-date -format ($culture.DateTimeFormat.DatePattern) New-Object psobject -Property @{“name”=$culture.displayname; “date”=$date} }
  5. I did. The problem is, that the Online Check fails. The conversion of the date from the registry key for the last contact to System.DateTime fails. Online Check is done by the following line of your module: $Online = If ((Test-Path "HKLM:\SOFTWARE\LabTech\Service") -and ((Get-Service ltservice).status) -eq "Running") {((( (Get-Date) - [System.DateTime](Get-ItemProperty "HKLM:\SOFTWARE\LabTech\Service").LastSuccessStatus).TotalSeconds) -lt 600)} Else {Write $False} and this fails:
  6. Found the Error. The Online check doesn't work, at least for me. It says the registry key can't be converted to System.DateTime.
  7. Yes, exactly. most of the computers we had this issue had neither a vpn connection nor the same MAC address but it seems like another reinstall fixed this issue. The problem here is that direct access to the machines is basically impossible. I can schedule scripts as Startup scripts to execute commands via GPO, thats mostly it. Your module produced following error for me: VERBOSE: @{ComputerName=HD-MTECH4; ServerAddress=https://10.10.x.x; ComputerID=; ClientID=; LocationID=2; Version=; InstFolder=True; InstRegistry=True; Installed=True; Service=Running; Online=} As install result. This is an error related to our connectwise instance. All downloaded installer packages include the internal IP of our server instead of the FQDN ... This was fixable by adding the server address again to both calls of the msiexec for agent install: Start-Process "msiexec.exe" -ArgumentList "/i $($SoftwareFullPath) /quiet /norestart LOCATION=$($LocationID) SERVERADDRESS=$($AutomateURL) Which would be great if you added that to the official powershell module. After installing again with this fix the agent installed correctly, the script still reported a fail: VERBOSE: @{ComputerName=HD-MTECH4; ServerAddress=https://"correctdomain".de; ComputerID=1555; ClientID=1; LocationID=2; Version=200.172; InstFolder=True; InstRegistry=True; Installed=True; Service=Running; Online=} The Automate Agent FAILED to Install
  8. Thanks I'll try that! The more I test the more errors surface at the moment ... We had Clients reuse an already taken ID yesterday, today we have new Clients not reporting to the automate server or showing up in the collector location even tho the location they should use is set ... Im almost full time fixing automate hickups for ~ 3 weeks now and I feel like Im turning mad slowly. 😅
  9. We are having trouble with the Ninite integration on our Connectwise Installation. Patching works fine, Caching is enabled but Cache Access fails. If the Cache is manually cleared and the cacheTest folder removed, the first client checks in, writes his testfile but then fails to read it. We've already tried different network shares as cache locations and different users for the cache access, even domain administrators but it still fails. Did anyone else have, and at best fix, this issue?
  10. We've had this same issue in many different ways. I just finished my own script to fix broken agents before I found this threat ... I did it quite simple: 1. check path of the agent 2. if not existant, install msi 3. read the registry entry for the server adress 4. if not matching the desired, stop services, fix entry 5. start services (because we also had some clients just not starting their services correctly) Maybe you wanna implement my step 3 and 4 at the end instead of doing a complete Rip and Replace on the next execution @Braingears? $AutomateSrvAddrReg = (Get-ItemProperty "HKLM:\SOFTWARE\LabTech\Service").'Server Address' If ($AutomateURL -ne $AutomateSrvAddrReg) { Get-Service lts* | Where {$_.status –eq 'Running'} | Stop-Service Set-ItemProperty -Path HKLM:\SOFTWARE\LabTech\Service 'Server Address' -Value $AutomateURL –Force }
  • Create New...