[LabTech] IPBlock Windows Firewall plugin.

Block entire countries from seeing your PC on the Internet

Squidwork’s garage has released version 1 of their new IPBlock for Labtech RMM. IPBlock is a Country based Network Firewall plugin for Windows based systems. When deployed you can select different countries you do not want to have access to your IP address for any Windows Vista / 7 / 2008 or new system and block them from network access to your PC.

How it works:

The plugin launches a script that goes out and refreshes a complete list of all countries and any IP ranges assigned to those countries. It imports them into the local host and stores them in zone files inside the LTSvc directory. Then based on your selection it applies each zone to the Windows firewall as a rule set.

What does this do for me?

This greatly reduces your Internet footprint and attack surface. Preventing access from countries that have large amounts of attacking systems. It also reduces your ability to be fully exploited by Trojans, Virus or Worms as if infected it makes it much harder to “Phone Home” if the attack comes from a Country you have blocked like “China”.

Version 1 only controls the lists that are applied to your PC it does not turn on or off the actual firewall on Windows. You will need to turn on firewall through the Windows control panel for rules to actually take effect. Then to stop the filtering shut down Windows firewall or go into plugin and select “None” and apply for all rule sets placed in by IPBlock to be removed.

Get Version 1.0.3 here

Enjoy Cubert 😎

APPAssureD – Dell AppAssure Backup Plugin For LabTech

A new plugin is under development here inside the Squidworks garage that allows Labtech MSPs to manage Dell Appassure Backup Cores servers from a common console inside of Labtech. The new plugin leverages Appassure REST API to mine data from each core and send that data back to the Labtech database. Using the same processes the plugin is able to send commands back to the cores to preform various tasks like start a new backup or replication.

The plugin provides a common view of each core at the location level console in Labtech. You can select one of many cores at any location and view the protected servers managed by that core. Selecting a protected server provides details about that server and the list of snapshots preformed on that system. We have many great features planed for this plugin so start following us now!

Client Console

Dashboard View

The plugin is still under development and will we have a release for early beta testers. Place a comment here you would like to be notified of updates and being included in the beta testing.

Get Version 1.0.1 Beta here

You Will need Powershell 3 on all Cores, Here is a script to install Powershell 3 directly from LabTech

Get PS Installer Script Here

LabTech & ConnectWise Plugin – Printer Health Status

Printer Health Status

Mr Keigher posted on the Labtech forums that wouldn’t it be great if there was a Printer Status Plugin for Labtech that could show if there were any issues with a printer and maybe even interact with a failed printer. Well Marty your ship has come in! Let me introduce you to your new Printer Status Plugin. The team down in Squidwork’s basement went to town taking what seemed like minutes (and it looks like it) to build a Labtech plugin that would do what had to be done.

In Version 1.0.4 you have good management over printers in 2 main views; the global view and the client view. The Global view allows for the full management suite of tools to be executed on any printer being scanned and will give you a quick view in to the troubles your clients maybe having. The Client view provides the same management functions but also allows you to enable and disable scanning for a client and to include desktops in printer scans.

Lets show you what we have:

Printer Status Global Manager:

Printer Status at the Client Console:

Printer Status Exclude Printers:

Download Labtech Plugin – Printer Status Version 1.0.4

Enjoy

Cubert

LabTech & ConnectWise ESXI Host Hardware Monitor

NEW ->LabTech ESXi Hardware Monitor v2.1

Squidwork’s ESX Hardware monitor is a set of scripts, a custom group and search for Labtech that will monitor the CIM data provided through the VMWare API for ESX 4 and 5. The probe will launch hourly and report back to Labtech any hardware failure or warning. The script will email an alarm to any email address you would like. The script can be modified to also set an alarm, create a ticket or anything else Labtech scripting will let you do.

New in version 2.1:

We added several checks for false alarms and socket errors to prevent alarms and emails on non failures.

We added alarm flood control, once a email goes out it will not send another until the system has reported a “all OK” then alerts are reset to go out on next fail.

Added extra EDFs to control processes.

Here is how it works:

Download the zip file, extract and import the XML files into your Labtech system.

Addendum Update:

After you import “all” scripts in Version 2.1 Download this zip and import this script. This script should then be used in your group scheduled script probe instead of the v2.1. This v.2.2 of that one script. Download update here

Download extra files directly if import fails for any reason here.

After the import you should have a VMware script group that has 3 scripts in it.

Script #1 (The Installer) will install the monitor to a Windows system. You will need to provide the FQDN or IP of the ESX host you want to monitor when you execute the installer script. When the scheduler pops up make sure to add your ESX host. The only thing you should need to do is execute the installer on a Windows system. The installer will configure the system and add the system to the custom group and search. You do not need to configure anything else at this point. The ESX user and password will be fetched from the Locations password menu for VMWare.

The next script (The Monitor) is assigned to the custom group “Systems that monitor ESX hosts” to run every hour. You can modify this to run at what interval you like. The Monitor will query your “Locations” passwords database table and retrieve the VMWare user listed just like the original Labtech probes do. The monitor get the CIM health data and returns it to Labtech, It also looks to see if we are “Not OK” and fires off a email if failures are picked up.

After the Monitor runs you should see data on the Info Tab -> VMWare sub tab

You will need to edit the monitor script updating the email address that it reports to when failures are found, you can also modify monitor script to create a ticket, fire off an alarm, set an alert or anything your heart desires. Line 39 of the script ESX Hardware Monitor V2-1 needs to be edited and the example@example.com email changed to the email you want to get the alerts.

The 3rd script is a updater script that will fetch the latest build of the Nagios Plugin:”check_esxi_hardware.py” script maintained by www.claudiokuenzler.com You can run this script against any Windows box that has the monitor installed and it will get the latest version of this script and deploy it to that system. This way you can keep up with all the fixes they do to this script. You may want to run this script on the group once or twice a year just to make sure you have the latest fixes and updates.

Enjoy

Cubert 😎

[Solved] Remote Web Workplace Stops Working on Windows SBS 2011with EventID 1309

When users attempts to click on the “Connect” link under “Computers” in attempts to launch remote web workplace nothing seems to happens. If you issue a IISreset then the system starts working again for a short time before starting to fail again. You check your logs and find EventID 1309 Event message: An unhandled exception has occurred.

It appears that it maybe some level of memory issue in .Net 4.5 and the Remote Access web.config set to default at a given memory level.

To Fix:

Edit (via NotePad) the web.config file located at “C:\Program Files\Windows Small Business Server\Bin\WebApp\RemoteAccess

Look for the following line at the bottom of web.config

<serviceHostingEnvironmentaspNetCompatibilityEnabled=”true” />

Replace that line with: (all on one line)

<serviceHostingEnvironment aspNetCompatibilityEnabled=”true” minFreeMemoryPercentageToActivateService=”0″ />

Save file and then restart the World Wide Web services to activate the changes.

Your Remote Web Workplace should now stay functional.

Enjoy..

Cubert 😎

LABTECH -> How To Have A Full Screen Remote Desktop Client Redirector

Create a Labtech Full Screen RDP Redirector

Labtech out of the box comes with a older version of RDP client that when is pushed to full screen looks really crappy. That’s not Labtech’s fault but the limitation of the RDP client they packaged with the LTClient software. One of the great things about Labtech is you can customize it to your needs, Labtech does not force you to use “what they have”.

Today I will walk you through creating a new redirector in Labtech and setting up a new full screen Remote Desktop Client function. Some of the things you will need are, admin access to your LT server and a Windows 7 workstation to harvest the mstsc.exe from. As stated above the mstsc.exe supplied with LT is old and limited, we will need a new mstsc.exe to do full screen like we want.

Lets get started!

First thing we need to do is copy our Windows 7 mstsc.exe to our LTClient directory and rename it.
goto %windir%\system32\mstsc.exe and copy and paste to c:\%programfiles%\LabTech Client\RDP\mstsc1.exe

Do not overwrite the existing mstsc.exe, create a new file and name it mstsc1.exe
Now find and edit the file c:\%programfiles%\LabTech Client\RDP\LabTech.rdp, select the Display Tab and move the slider to full screen. Go back to the General Tab and select “Save As” and save as LabTech1.rdp
Do not overwrite the existing LabTech.rdp, save as a new file and name it LabTech1.rdp

Now if everything was saved correctly you should have a Labtech Client\RDP directory that looks like this.

Notice the file sizes of each mstsc.exe file?
Now come the fun stuff, creating the redirector in Labtech. Lets open up the LT Dashboard and select Config Tab -> Configuration Tab -> Redirected Apps Tab.
Lets create a new redirector using the following information.
Name: Remote Desktop(Full)

Program: %windir%\system32\CMD.exe

Arguments: /c Type “%programfiles%\LabTech Client\RDP\LabTech1.rdp”>”%temp%\%computername%.rdp” & START “RDP” /WAIT “%programfiles%\LabTech Client\RDP\mstsc1.exe” “%temp%\%computername%.rdp” /public /V:%localip1%:%localport1%

Redirector Type: Check Device, Check Computer

:Redirector Port:
Local Port = 0
LocalIP = 127.0.0.2
RemotePort= %managementport%
RemoteIP = %AltRemoteIP%
SocketType = TCP Local Listen

If all went well you should be able to reload your cache on the LT Client and then see the new redirector you created on your network redirectors menu.

Now when you launch your new redirector you should see things happen a bit differently from the original Remote Desktop connection that Labtech uses.

Your STun should be the same as any other RDP Session:

But now you should be presented with a new Remote Desktop Connection box:

Followed by a Windows Security dialog box:

Make sure to input the domain name your connecting to in with the administrator account to access system. If it populates with a previous connections domain name and you would like it to forget those credentials when new connections are created then follow my step by step instructions located on one of my other blogs -> Drop Credentials.

Now if you have multiple techs working for you and they all want the RDP full screen function then they will need a copy of the 2 files we created above. I created a Labtech script to copy the files from my LT transfer directory to the local LTClient directory as needed then push that to all tech computers so they also have the required files locally. If you ever need to update the files then it makes it easy to resend them to everyone who needs them.
Good Luck

Cubert 😎

{Solved} Appassure 5 -> Error occurred pairing to agent at URL

Replay.Core.Contracts.Agents.AgentPairingFailedException: Error occurred pairing to agent at URL

Here is several possible fixes for this type of error based on state of agent systems, Each fix is based on a given type of problem. I will continue to post other fixes for this error type as I come across them.

New Agent Install on Windows DC or SBS server.

So you just installed an Appassure 5 core server and now are trying to protect a new Windows domain controller or maybe an Microsoft SBS server and you keep getting the following errors.

There is a quick fix that worked great for me when this happened to me during a deployment to a Microsoft SBS 2011 system. Found it to be an issue when the TLS client authentication fails between Unified Communications peers where the Configure Group Policy to ignore the list of trusted certification authorities on the computer that hosts the UC client is disabled.

Open up REGEDIT on the core and agent system and add a DWord to following key.

HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Add Dword -> SendTrustedIssuerList with a value of zero.

Now restart the core and agent services and retry to protect server.

It should connect and add new server to core as expected.

————————————————————————————————————–

Agents Previously Paired on Another Core

If after removing an agent from protection on a Core that protects other agents, you receive an error asking you to repair the orphaned agent when you attempt to re-add it to protection on a new Core. During the repair it fails with same error “Error occurred pairing to agent at URL” and the stack trace shows the error below.

Stack Trace Error:

Call to service method https://localhost:8006/apprecovery/api/core/agents/pairing/repairOrphan POST failed: Error occurred pairing to agent at URL ‘https://anvil-hosting:8006/apprecovery/api/agent/’

Replay.Core.Contracts.Agents.AgentPairingFailedException: Error occurred pairing to agent at URL ‘https://anvil-hosting:8006/apprecovery/api/agent/’ —> WCFClientBase.HttpUnauthorizedRequestException: Call to service method https://anvil-hosting:8006/apprecovery/api/agent/pair/connect GET failed at WCFClientBase.ClientBase.HandleResponse(Uri uri, String method, HttpResponseMessage response) at WCFClientBase.ClientBase.GetResponse(Uri uri, String method, String knownEtag) at WCFClientBase.ClientBase.ExecuteServiceCall[T](Uri uri, String method) at Replay.Core.Implementation.Agents.AgentsService.VerifyPairedAgentConnectivity(AgentDescriptor agentDescriptor) at Replay.Core.Implementation.Agents.AgentsService.AddOrRepairProtectedAgent(AgentDescriptor agentDescriptor, Boolean isOrphaned)

Follow this process to to remove the connection information in the registry of the Cores and Agents involved in the moves.

On the old and new Core servers:

Open the registry editor and navigate to HKEY_LOCAL_MACHINE\Software\AppRecovery
Verify that the agent’s registry key no longer displays this specific agent ID.

On the agent systems:

Stop the Agent Service.
Open the registry editor and navigate to HKEY_LOCAL_MACHINE\Software\AppRecovery.
Export and verify that the old Core pairing is still visible under the Pairing settings.
Delete the entire agent’s key.
Start the Agent Service.

Now Protect the agent once again after all services have been restarted. You should not get any orphan or repair warnings and the system should complete without errors.

Goodluck

Cubert 😎

[Solved] – Dcdiag fails for NCSecDesc test and adprep /rodcprep fails to fix it.

This was a real pain and we ended up having to call Microsoft and spend several hours to resolve what seem to be a simple issue. When running dcdiag you get an error that the NCSecDesc test failed with:

Error NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS doesn’t have Replicating Directory Changes In Filtered Set access rights for the naming context: DC=cosgro,DC=com

Normally running adprep /rodcprep at the command line would correct the issues but in this case we kept getting the same response when running adprep.

Adprep detected the operation on partition DC=ForestDnsZones,DC=cosgro,DC=com has been performed. Skipping to next partition. ============================================================================== Adprep detected the operation on partition DC=DomainDnsZones,DC=cosgro,DC=com has been performed. Skipping to next partition. ============================================================================== Adprep detected the operation on partition DC=cosgro,DC=com has been performe d. Skipping to next partition. ============================================================================== Adprep completed without errors. All partitions are updated. See the ADPrep.log in directory C:\Windows\debug\adprep\logs\20130213141646 for more information.

And when we re ran DCDiag we would still get the same error. All the online documents say this should of resolved the issues but it had not.

The problem was not the ADPrep /rodcprep but the permissions were seen to be to “open” for the Enterprise Domain Controllers Group. The security permissions for this group was set to “full” on the main domain partition. This set of permissions needed to be more restrictive for the group. To fix we needed to open ADSI Edit and reset the permissions on the domain partition.

The picture below shows you where the domain partition resides, right click the partition and select properties.

Then on the pop up windows select the security tab. In the Groups and Users box find the “Enterprise Domain Controllers” group and then uncheck all permissions.

Now re-add only the list below to the allow column.

Manage replication topology
Replicating Directory Changes
Replicating Directory Changes All
Replicating Directory Changes In Filtered Set
Replication Synchronization

Apply the changes and rerun DCDiag to verify that the changes are working.

Thats it.

Enjoy Cubert 😎

2 Common Issues With Microsoft Terminal Services

Many WAN connections can vary in quality and latency, and often times these two characteristics will manifest themselves in disconnected terminal services sessions. By doing two relatively easy registry hacks, you can reduce these disconnects and improve the overall experience of your users.

Keep Alives:

In the registry at HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server, create or edit the DWORD value of KeepAliveEnable and set it to 1. This will turn Keep Alives on. This will serve to stabilize the connection by sending ‘heartbeat’ packets to the client every so often. This will cause an idle connection to be probed every so often just to be sure that the connection is still alive and that the client is still listening on the other side. This will also help prevent disconnects by preventing network devices from killing off sockets that it assumes to be idle. By turning on Keep Alives, the connection will not appear idle, and therefore the network device will not attempt to terminate the socket.

Two other registry entries to look at are at HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveInterval and HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveTime. KeepAliveInterval determines the interval separating keep alive retransmissions until a response is received. If a response is received, the delay until the next keep alive transmission is again controlled by the value of KeepAliveTime. KeepAliveTime controls how often TCP attempts to verify that an idle connection is still intact by sending a keep alive packet. If the remote system is still reachable and functioning, it will acknowledge the keep alive transmission.

TcpMaxDataRetransmissions:

In the registry at HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters, create or edit the DWORD value of TcpMaxDataRetransmissions. By default it is set to 5, but I would recommend doubling that value, to 10. The value of TcpMaxDataRetransmissions is the number of times TCP retransmits an unacknowledged data segment on an existing connection. TCP retransmits data segments until they are acknowledged or until this value expires.

Enjoy..

[Kaseya Agent Procedure] VMWare ESXi Hardware Health Monitor

VMWare ESXi Hardware Health Monitor Script

From the skunk works here at Squidworks comes another great monitoring script for Kaseya.

This script uses the SDK provided by VMWare to query the ESX host and return a good or bad variable. If the hardware test fails then the script grabs the log of the test and uploads it to Kaseya Server then places it under the “Get File” area for the host that ran the test. You can run this script on any windows box, I have also included the current vSphere SDK installer and a Kaseya script to install it if it is not found on the Windows Host.

Upload the SDK installer and Import the scripts to your public files area in Kaseya under the directory “VMWare”. If you place files anywhere else you will need to edit script for the new location of files.

The script then makes a unique event log entry into the Windows Application Event Log under the Application Events that can then be picked up by Kaseya’s Event Log Monitor. When Kaseya picks up this event you can instruct the monitor to create an alarm, create a ticket, run another agent procedure or email the alarm to an address(s). Just schedule the agent procedure to run a couple of times a day to keep an eye on your customers VMware vSphere ESXi Hardware health.

This script links to the CIM information provided by the hardware to the ESX host. You will see CPU, Memory, Fans, RAID and Controller Health. The log file that is uploaded will only show failures and will tell you what failed and on what ESX host.

Download -> Kaseya VMWare ESXi Hardware Monitor

Enjoy

Cubert 😎