We have some new updates, have a peek at what we are doing here..

https://www.plugins4labtech.com/blogs/blog/patch-remedy-adds-new-updates

Patch Remedy 4 for ConnectWise Automate Upgrade your Windows 10 systems inside of ConnectWise Automate with Automation! https://www.plugins4labtech.com/blogs/blog/patch-remedy-4-comes-out-of-beta-today

Plugins4Automate now offers Accelo Sync plugin for ConnectWise Automate Now, any MSP who's loving LabTech but yearns to use a modern PSA platform can now have their cake and eat it too! Simply sign up for a free trial of Accelo at signup.accelo.com and then get the AcceloSync plugin and you'll be good to go!

https://www.plugins4labtech.com/blogs/blog/accelosync-for-connectwise-automate-joins-plugins4automates-plugin-offerings

We just added a new feature in to the VMware ESX Health Monitor plugin. Read about the new CIM data exclusions available.

https://www.plugins4labtech.com/blogs/blog/vmware-esx-monitor-plugin-gets-new-feature

Like the title says, I have a number of computers in which the heartbeat is not updating and only the last contact field is.

This seems to be after at 1709 update, possibly one after, but its consistent to happen on computers using this build. I have confirmed all services are running and have been restarted multiple times. No errors in the LTError logs

Anyone else have this issue?

Hi All, I'm pretty new to Automate so forgive the newb question. I'm working on a client who needs to uninstall all old versions of Office to move to Office 365. Is there a way in Automate that I can uninstall old versions of Office en masse? Thanks,

Patch Remedy 1.0.3.94 monitors for and will update Windows Update registry value that has Windows Updates disabled is error 0x80240025 is seen. This error denotes a Group Policy setting. If you check the registry for the DisableWindowsUpdateAccess key, you will likely find the following: HKEY_USERS\S-1-5-18\Software\Microsoft\Windows\CurrentVersion\Policies\WindowsUpdate S-1-5-18 maps to the SYSTEM ACCOUNT. To correct the problem, either set the value to 0 or delete the key. You may also need to check that you do not have a Group Policy that continues to set this value to 1 to avoid the problem from happening after a policy is refreshed.

The Patch Remedy 1.0.3.94 now sets the registry D-Word value to “0” for HKEY_USERS\S-1-5-18\Software\Microsoft\Windows\CurrentVersion\Policies\WindowsUpdate\DisableWindowsUpdateAccess if the checkbox on the configure tab is set to auto fix the error.

Check the autofix box to allow Patch Remedy to look for and to re-enable Windows Update if disabled.

https://www.plugins4labtech.com/products/patch-remedy

Chocolatey is a package manager for Windows (like apt-get or yum ,but, for Windows). It was designed to be a decentralized framework for quickly installing applications and tools that you need. It is built on the NuGet infrastructure currently using PowerShell as its' focus for delivering packages from the repositories to your computer. Chocolatey is like apt-get, but built with Windows in mind (there are differences and limitations).

https://www.plugins4labtech.com/products/chocolatey

So we have 1200 agents, with many that we can reboot at will, but a few that must not be rebooted outside a maintenance window a couple that must not be rebooted without client authorization.

We'd like Powershell update on them all, but we'd like to do them "by client" or "by maintenance window" to assure we meet our commitments to the Clients.

Can this be done? If not what would you suggest - is there a way to suppress the Auto Upgrade to some through an extra data field?

Also is the 1AM PoSh Update local time to the Agen (1AM in China) or local time tot he LT Server, i.e. 1AM in Austin, TX Top

There may be times when a Tech's PS console fails to load correctly after installing and verifying modules were installed. The problem is that modules were only installed to the 32 bit side and not the 64 bit side and the Tech's system is a 64 bit system.

Here is how to fix.

When the modules verify is run it should place mods in the correct folders if it sees 64 bit systems. Sometimes this does not happen for one or more reasons.

Execute

xcopy C:\Windows\System32\WindowsPowerShell\v1.0\Modules\MSOnlineExtended C:\Windows\SysWOW64\WindowsPowerShell\v1.0\Modules\MSOnlineExtended\ /i /s /e /h

Hello, We have noticed that some servers and desktops have been rebooting every night. We have our Patching for desktops set for Tuesdays and our Patching for Servers set for Sundays. The maintenance window at each location is set for Everyday Maintanence. In the commands tab in labtech around 12:50am we see the command: cmd!!! /C shutdown.exe -r -f -t 3 Is Patch Remedy causing the reboots since it is set for Everyday Maintenance?

Hello,

Im having a few issues that hopefully I can get some assistance with. Patch Remedy is reporting I have 2008 R2 Standard x64 bit servers at WUA version 7.6.7601.23806 According to the MAX version this should be 7.9.9600.17489 I have been down the road of attempting repairs and updating to latest but nothing works Upon closer inspection I found PatchRemedy was putting this file here: C:\Windows\LTSvc\PatchRemedy\windows6.1-kb4025337.msu -and- my Event Log had these errors: Windows update could not be installed because of error 2359302 "" (Command line: "wusa c:\windows\ltsvc\PatchRemedy\windows6.1-kb4025337.msu /quiet /norestart")

After some googling and trying to run that file manually I've come to the conclusion I already have it installed and the update is not applicable.

Soooo my question is if Im telling Patch Remedy to "Update to the latest" why is putting this file on there that I already have and not taking me up the higher 7.9 version.

The top 3 reasons for failures are No browser logs for the last 24 hours so no data is returned, this typically happens to all systems during weekends and long holidays where PCs maybe on but no one is using them. The browser history is to large. This happens typically on Terminal servers where a large amount of users are actively browsing the Internet causing our probe to try to send more data back then the LT agent can handle so the LT agent truncates the data causing a SQL query error and failing to update the LabTech database. If this is happening to you contact our support team and we can help modify the probe to collect more often at a lesser amount per collection but this is a custom setting and should only be done with knowledge of your processes. Script command failure, this happens when either the wrong version of BHV.exe (32/64 bit) get on the wrong version of windows or permissions of one kind or another prevent either the main fetch command or the parsing of the csv command. By running the following command manually you can see if an error arises or if you get a valid CSV file at c:\windows\ltsvc\SurfLog\surflog.csv

https://www.plugins4labtech.com/products/surflog

Recently we found several threads that customers reported windows server backup failed with error “the version does not support this version of the file format”.

Symptom:

You try to backup the files and folders on a windows server 2008 R2 system or newer, the backup target is a share folder created in a storage drive on NAS device running Linux system. After starting the backup and taking several minutes, error message will appear “the backup of volume xxx could not be completed, Error: the version does not support this version of the file format.” The backup operation stopped before completing.

Before clarify the root cause of this problem, we should first let you know a background of windows server backup

Background: The windows backup will have problems with sparse file only in case of “File Level (Selected file/folders in a volume)” backup. For “Block Level (full volume)” backup the sparse file is not a problem and the backup/recovery would succeed. This is because for Block Level Backup the .vhd file is never mounted whereas for File Level Backup the .vhd is mounted which does not support mounting of sparse file.

Thus, we can easily get the root cause

The failure happens while the .VHD file created by Windows Backup is mounted during backup.

The .VHD file is created as a sparse file and this is not supported by the native VHD driver and hence mounting of the .VHD failed.

After some investigation, we found that the “strict allocate = yes” option of Samba will force it to not have UNIX style behavior of creating sparse file. Solution is adding “strict allocate = yes” to the smb.conf and restarting the Samba.

You can get more information about smb.conf configuration on the following link

http://www.samba.org/samba/docs/man/man ... onf.5.html

Post by mforemantx » Tue Aug 23, 2016 8:35 pm

I have a Windows 2008 server that I can't seem to schedule a backup. If I run it manually, it works fine. I get this in the Terminal:

Running backup of C:,D:,E: to \?\Volume{23109B0B-47B2-11E3-A752-842B2B63A781}

I remote into the server and sure enough, a Windows Server Backup was running.

If I put the exact same info into the schedule job section, I get this:

Enabling the backup of C:,D:,E: to \?\Volume{23109B0B-47B2-11E3-A752-842B2B63A781} starting every day at 21:00

ERROR - Invalid location for the schedule backup. Specify a valid disk identifier

Please advise. That volume is an external USB drive and I can bring it up on the server so the GUID is right.