Here is a quick powershell one liner that I came up with when I got a request from Microsoft Support to disable user protocols. I did some research and found out that they meant the protocols or services used to access Office 365 Exchange Online.
God has recently lead me to do some charity volunteer work for a worldwide organization and their IT department. My first project was to untangle their Nagios Core system and then take over the administration of that server and the monitoring of the rest of the network. Part of this volunteer work took place yesterday with deep dive into the Nagios framework, Linux and SNMP to allow monitoring APC UPS devices.
Initial Trip Off Course
My initial thought was not to re-invent the wheel and head to the Nagios Exchange to find a pre-made project that would elegantly provide monitoring APC UPS devices. I found the check_apcupsd project which looked simple and had a great screenshot. Little did I know what I was getting into. Turns out there are a couple undocumented dependencies for this including apcupsd itself and an undocumented connection to port 3551 which I could not find inside the portal page for the SMART-UPS 1500 network management card. After a couple hours of frustration I abandoned this and removed all linux packages associated with it.
Trip Down SNMP lane
After looking over other projects at the Nagios Exchange, I decided to research using SNMP to provide monitoring APC UPS devices. This lead me to an article by Mihai Radoveanu which provided the detailed steps to create monitoring APC UPS devices in Nagios Core. He details editing the command.cfg file to add the check_snmp and his own check_snmp_inverter to list of commands. (Please note that the check_snmp_inverter.sh file will need to be edited to Change the Home variable to point to the Nagios Core plugins directory) He details creating host templates, host groups, adding a separate configuration file to the main file which includes hosts and services. I prefer the more standards based approach to creating individual host files, adding them to a host group and then creating a service file that points to the host group. Made these changes to the Nagios Core framework and confirmed my configuration before making the changes live.
APC Changes Needed
Finally came the changes to the APC UPS network management card configuration:
Login to the network management card webpage, click on Configuration > Network > SNMPv1 > Access then check the box next to Enable and click on Apply.
Click on Configuration > Network > SNMPv1 > Access Control then click on a community name then type in the network SNMP community name and the IP address of the Nagios Core server. It will only need Read permissions. Click on Apply.
That is all that is needed. This introduction to the Nagios Core framework later allowed me to setup SNMP monitoring for the High Availability link ports between their Sonicwall 4600 devices.
If you are looking for expert monitoring of your network systems by highly trained technicians, then contact us for assistance.
The following steps will setup Windows Server 2012 R2 RADIUS authentication via Network Policy Server (NPS) with your Ubiquiti UniFi Security Gateway (USG) for a USG Remote User VPN. This will allow users to use their current Active Directory Domain Services (AD DS) credentials to authenticate to the Virtual Private Network (VPN).
I am using the UniFi controller version 5.4.14 hosted in Microsoft Azure on a Linux Server with PostFix for alerting.
Step 1: Configure Windows NPS Server
From the Server Manager Dashboard, install the Network Policy and Access Server role using Add Roles and Features accepting all defaults.
Once installed, open the Network Policy Server Administrator Tool. Expand the RADIUS Clients and Servers, then right Click on RADIUS Clients and click New.
Give the USG router a Friendly Name. Type in the IP Address of the inside interface of the USG on the same network as the Windows Server. (This is the IP that the RADIUS requests will come from.) Click the Generate radio button, then click the generate button. Copy this Shared Secret to be pasted later. Click OK.
In the Network Policy Server window, expand Policies, right click on Network Policies, and then click New.
Enter a policy name and leave Type of Network Access Server as Unspecified. Click on Next.
In Specify Conditions click Add.. and then select Windows Group, and pick the AD Group you want to use to allow VPN access. (If you have not already then you will need to add all users who will be accessing the VPN into a seperate group.) Click Add… then Add Groups… which brings up the typical AD search box. Type in the name of the VPN Windows Group and click on OK. Click OK again. Click on Next
Leave the Specify Access Permissions at the defaults (Access Granted, Dial-in box unchecked). Click Next.
Uncheck all authentication methods other than MS-CHAPv2. Click on Next.
Accept the defaults under Configure Constraints. Click Next.
Leave all setting at the default on this page except for under Encryption. Uncheck everything except for MPPE 128-bit. Click Next.
Check your settings on the last page. Click Finish.
Finally, move the new policy above the two default policies in the list by right clicking and choosing Move Up.
Step 2: Configure the USG Remote User VPN
To create the remote access network, in the UniFi controller, go to Settings, then Networks, and click Create New Network, give the network a name and select Remote User VPN.
Fill in the appropriate Gateway/Subnet information for your environment. Make sure it is not the same as any of your current networks.
Add Manual DNS servers, if required for your environment.
Click on Create New RADIUS Profile.
Give the Profile a name, enter in the IP address of the Windows Server 2012 R2 server that will be used for RADIUS authentication and paste in the generated shared secret.
Click Save. Click on Save again.
This allows easy access from Windows default VPN connections to network assets behind the USG device.
If your company is currently using a Ubiquiti USG device and need a Remote User VPN setup, then contact us for assistance.
Ransomware attacks continue to spread around the world this weekend, after the initial damage inflicted on healthcare organizations in Europe on Friday.
The criminals responsible for exploiting the Eternal Blue flaw haven’t yet been identified, but up to 100 countries have hit with WannaCry ransomware, with Russia, Ukraine and Taiwan among the top targets.
The ransomware first appeared in March, and is using the NSA 0-day Eternal Blue and Double Pulsar exploits first made available earlier this year by a group called the Shadow Brokers. The initial spread of the malware was through email, including fake invoices, job offers and other lures with a .zip file that initiates the WannaCry infection. The worm-like Eternal Blue can exploit a flaw in the Server Message Block (SMB) in Microsoft Windows, which can allow remote code execution. This flaw was patched in Microsoft’s March 2017 update cycle, but many organizations had not run the patch or were using unsupported legacy technology like XP.
What’s New
Today, Microsoft has released emergency security patches to defend against the malware for unsupported versions of Windows, including XP and Server 2003.
Overnight and today, it has become clear that a kill switch was included in the code. When it detects a specific web domain exists—created earlier today—it halts the spread of malware. You can learn more at The Register.
As a Webroot customer, are you protected? YES.
Webroot SecureAnywhere does currently protect you from WannaCry ransomware.
In simple terms, although this ransomware is currently causing havoc across the globe, the ransomware itself is similar to what we have seen before. It’s the advanced delivery mechanism that has unfortunately caught many organizations off guard.
In addition to deploying Webroot SecureAnywhere as part of a strong endpoint control strategy, it is essential you continue to keep your systems up-to-date on the latest software versions and invest in user education on the dangers of phishing, ransomware, social engineering and other common attack vectors.
If you have any questions about your Webroot deployment, reach out to our Support Team now.
You are a critical part of our business. Our Managed Service Providers have asked us to write you to explain why our Webroot SecureAnywhere Business Endpoint Protection experienced performance issues, and what we are doing to resolve those
issues as quickly as possible.
Yesterday, Webroot released a rule that categorized some legitimate files as malware. As a result, multiple legitimate business applications were quarantined and unable to function. This rule change was in effect for 13 minutes on Monday, April 24. To be clear, this rule change was caused by Webroot and not your Managed Service Provider.
Webroot is continuing to work diligently with our partners to restore functionality for our mutual customers. While the false positives that caused the incident have been stopped, we are still working on an automated fix to reverse the files affected. Any
resolution will be released immediately.
Webroot is a trusted partner of many Managed Services Providers and this incident is not representative of our high standards. We always strive to be open and transparent, and we are working tirelessly to fix the issue. Once Webroot has identified the root cause, we will ensure further controls are in place to prevent an
incident like this from happening again.
We apologize for the pain this has caused you. Webroot appreciates your business, and our entire team is dedicated to being your most trusted Partner.
Thank you for your patience as we work through this incident.
This article will leave out the names of the internet providers to protect against defamation of character issues, but they include a local cable internet provider and a local reseller of DSL connections who also provide T1 lines. Had a client that recently changed from using a bonded T1 line to cable internet in order to get substantially better speeds. During the winter months they experienced the issues that are typical for remote installations of cable – downtime due to issues with the vendors hardware on the poles. After consulting with them, it was decided to go with a DSL PPPoE failover connection as part of some more expansive upgrades. Here is the setup that had to take place on the provided C1100Z modem / router and the Ubiquiti USG Pro.
Setup of C1100Z Modem Router
The modem / router defaults to router mode, which puts all traffic behind a Network Address Translation (NAT) router and allows this DSL vendor their usual practice of monitoring and reselling traffic information. I chose instead to change the settings to make the device into a standard modem in “Transparent Bridge” mode. You will need to contact the DSL vendor in question to get the PPPoE username and password before performing these steps to ensure that you can setup the Ubiquiti USG Pro later. Here are the steps from their website:
1. Open a web browser and go to http://192.168.0.1.
2. Login to your modem by doing the following:
Enter the Administrator Username
Enter the Administrator Password
Select “Apply”.
3. Select “Advanced Setup”.
4.. Select “WAN Settings”.
5. Select “Transparent Bridging”.
6. Select “Tagged-201” for the transport mode.
7. Select “Apply” to save your changes.
Setup of DSL PPPoE Failover Connection on Ubiquiti USG Pro
The second part of this is to setup the failover portion of the Ubiquiti USG Pro to use the PPPoE Connection.
Login to your Ubiquiti Controller
Choose the correct site from the list at the top right
Click on the Devices icon on the left hand column
Click on the Ubiquiti USG Pro device at that site to open up its properties
Click on Configuration
Expand the WAN2 connection and add the username / password acquired from the vendor earlier along with the preferred DNS then make sure to choose the Load Balancing type as Failover then Queue Changes and Apply Changes
This will setup the DSL PPPoE failover connection to be used whenever the primary WAN1 connection goes down. If your company is currently using an unreliable internet provider and need to setup failover, then contact us for assistance.
Proper care and maintenance of external hard drives keeps small business data secure and ensures reliable backup performance.
Your external hard drives are more than just storage devices—they’re the backbone of your backup and disaster recovery strategy. Whether you’re safeguarding financial records, client data, or project files, keeping these drives in top condition is crucial to prevent data loss and ensure smooth operations. Yet, many small- to medium-sized businesses (SMBs) neglect proper external hard drive care until it’s too late.
This guide outlines practical steps your business and IT team can take to maintain your external drives, answers common questions, and explains how Farmhouse Networking can help you protect your data investment.
Step-by-Step External Hard Drive Care for Businesses
1. Store Drives Safely and Strategically Keep your external hard drives in a cool, dry environment away from heat sources, direct sunlight, and moisture. Avoid stacking them or placing them near magnets or heavy equipment. A temperature-controlled office with minimal dust exposure reduces the risk of drive failure.
2. Use Regular Backup and Testing Routines Set up scheduled backups (daily, weekly, or monthly) depending on how often your business data changes. Test your backups regularly by restoring sample files to confirm they’re not corrupted. This extra step ensures your data will be recoverable when it truly counts.
3. Avoid Unplugging During Use Never disconnect an external hard drive while it’s transferring data. Doing so can interrupt write processes, causing data corruption or even physical disk damage. Always use the “Safely Remove Hardware” option before unplugging.
4. Protect Against Electrical Surges Use surge protectors or uninterruptible power supplies (UPS) to prevent sudden voltage spikes or power failures from damaging your drives. Power fluctuations are one of the leading causes of hardware failure.
5. Label and Track Your Drives For businesses using multiple backups or rotating drives, label each device clearly with its backup date, purpose, and drive ID. Maintain a simple log so your IT team can easily identify which drive holds which data.
6. Encrypt and Password-Protect Sensitive Data Even if your drives are physically safe, data security remains a top priority. Enable encryption and use strong passwords to protect sensitive company and client information, especially for industries handling confidential data or regulated information.
7. Monitor Drive Health Use disk-monitoring software to check drive health indicators like temperature, bad sectors, or read/write errors. Common tools include CrystalDiskInfo or SMART monitoring utilities—many of which can integrate directly into business IT systems for proactive alerts.
Common Questions About External Hard Drive Maintenance
Q: How often should my business replace external drives? Generally, replace drives every 3–5 years, depending on usage and storage environment. Drives used for daily backups may wear faster than those used occasionally for archiving.
Q: What’s the best file system for business backups? For Windows users, NTFS offers stability and large file support. Cross-platform users (macOS and Windows) may prefer exFAT. The choice depends on your backup software and workflow.
Q: How can I tell if my external hard drive is failing? Warning signs include slower performance, clicking or grinding noises, frequent disconnections, or error messages. At the first sign of trouble, stop using the drive immediately and back up data elsewhere to prevent further damage.
Q: Are SSD external drives better than HDDs? Solid-state drives (SSDs) are faster and more durable (no moving parts), but typically more expensive per gigabyte. SMBs focused on speed and portability often find them worth the investment.
How Farmhouse Networking Can Help
At Farmhouse Networking, we partner with small- and medium-sized businesses to create comprehensive data protection plans that go beyond just devices. Our team offers:
Automated backup solutions that reduce the risk of human error.
Drive health monitoring systems to detect early signs of failure.
Data encryption and security compliance consulting to safeguard sensitive information.
Disaster recovery services that ensure your business can bounce back quickly from any data loss event.
We understand how critical reliable storage is to your operations. Our IT experts can assess your current backup process, recommend appropriate external drives, secure your devices, and set up reliable offsite backups or cloud redundancy.
Keep Your Data Safe — Start Today
External hard drives are a dependable and affordable part of any SMB’s data management strategy, but they require proper care to remain effective. By following the steps above and partnering with a trusted IT service provider like Farmhouse Networking, you can extend the life of your drives, reduce risk, and maintain business continuity.
Ready to strengthen your backup strategy or troubleshoot your current storage setup? Email support@farmhousenetworking.com today to learn how Farmhouse Networking can help protect your business from data loss.
Had another tech firm that needed some Tier 3 assistance as they were having trouble with their VPN connection. I helped them setup Azure to Unifi USG IPSec VPN to connect their headquarters to the hosted RemoteApps server. This tutorial will go into detail about the creation of this tunnel starting with the Microsoft Azure side first using Resource Manager. It will be using the following parameters:
VNet Name: TestNetwork
Address Space: 10.10.0.0/16
Subnets:
Primary: 10.10.10.0/24
GatewaySubnet: 10.10.0.0/24
Resource Group: TestResourceGroup
Location: West US
DNS Server: Azure Default
Gateway Name: TestVPNGateway
Public IP: TestVPNGatewayIP
VPN Type: Route-based
Connection Type: Site-to-site (IPsec)
Gateway Type: VPN
Local Network Gateway Name: TestSite
Local Subnet: 10.20.20.0/24
Connection Name: VPNtoTestSite
Configure an Azure VPN gateway
This part takes the longest, so it should be done first:
Click on the “+” icon at the top left hand side of the Resource Manager, then search for “Virtual Network Gateway” and click on the “Create” button.
Give the Virtual Network Gateway a name
Select matching Region to where Azure resources are located
Leave Gateway & VPN type the defaults
Choose a SKU <- These have changed since the article was created, so my “standard” now is WpnGw1 with Active / Active turned off (this is a good balance of performance and cost)
Choose or create a local network (not covered here) that matches internal resources
Choose or create a Public IP Address
Leave the remaining values as their defaults and then click the “Create” button. (Please note the reminder that this takes 45 minutes to create!)
Configure an Azure Local Network Gateway
This is a reference to your on-premise network so that subnets can pass traffic:
Click on the “+” icon at the top left hand side of the Resource Manager, then search for “Local Network Gateway” and click on the “Create” button.
Give the Local Network Gateway a name
Select matching Region to where Azure resources are located
Specify the external IP address of the local on-premise site
Specify the on-premise address space (subnet)
Leave the remaining values as their defaults and then click the “Create” button.
Configure an Azure VPN Connection
This will create the tunnel from Azure to the on-premise site:
Click on the “+” icon at the top left hand side of the Resource Manager, then search for “Connection” and click on the “Create” button.
Choose “Site-to-site (IPSec)” as the connection type
Give the Connection a name
Select matching Region to where Azure resources are located
Leave the remaining values as their defaults and then click the “OK” button. On the summary screen click on the “OK” button to create the connection.
Choose the newly created Virtual Network Gateway
Choose the newly created Local Network Gateway
Specify a shared key
Leave the remaining values as their defaults and click the “Create” button.
This completes the setup of the Azure side of the VPN tunnel. Now to work on the Ubiquiti USG side.
Configuring an Ubiquiti USG VPN Network
This is a fairly simple process but it has to be precise:
Choose the Current Site from the top right hand side of the portal.
Click on the Settings gears down on the bottom left side of the portal.
Click on Networks then on the “Create New Network” button.
Give the connection a name, choose “Site-to-Site VPN” as the Purpose
Choose “IPSec VPN” as the VPN Type
Choose to Enable this Site-to-Site VPN
Add the Azure subnet under Remote Subnets
Get the newly created Virtual Network Gateway IP address from Azure for the Peer IP
Enter the on-premise external IP address for Local WAN IP
Enter the same shared key as used in the Azure VPN Connection for the Pre-Shared Key
Choose “Azure Dynamic Routing” as the IPSec Profile
Expand Advanced Options
Leave Key Exchange Version, Encryption, Hash & DH Group as default and uncheck the PFS & Dynamic Routing boxes.
That is all there is to it. If you have any difficulties with connection then delete and re-create the Ubiquiti USG side first (those two check boxes at the bottom of the Advanced Options will check themselves again, but don’t be fooled by this quirk in the software). If your company is currently using either Microsoft Azure or Ubiquiti USG routers and would like a VPN created, then contact us for assistance.
Recently did some Tier 3 support work for another technology company that was trying to setup a Windows Server 2016 RemoteApps server in Azure that would allow connectivity to remote users for their on-premise software. The process started with creating a VPN tunnel between on-premise and Azure, but that is a discussion for a future set of blog posts. Once this connection was in place, the company tried to use an external certificate for RemoteApps setup on the server. This would have been fine if the internal domain had not been a “.local” address scheme. This tutorial assumes that you have already installed Remote Desktop Services on a server and configured it to use the CA provided external certificate.
Change Remote Computer Name
One of the main sticking points that caused issues with security warnings for clients connecting is they would see the warning – “The remote computer could not be authenticated due to problems with its security certificate.” The fix for this has been graciously scripted in PowerShell by someone with the handle “TP” on Technet. The script is called Set-RDPublihedName.ps1 and is used as follows:
Set-RDPublishedName "remote.domain.com"
Proper Active Directory Group
There were then issues with the login process that caused the following error:
Remote Desktop can’t connect to the remote computer “<End Resource Name>” for one of these reasons:
1) Your user account is not authorized to access the RD Gateway “<RD Gateway Server Name>”
2) Your computer is not authorized to access the RD Gateway “<RD Gateway Server Name>”
3) You are using an incompatible authentication method (for example, the RD Gateway might be expecting a smart card but you provided a password)
This was coupled with Security Log messages – “The Network Policy Server was unable to connect to a domain controller in the domain where the account is located. Because of this, authentication and authorization for the RADIUS request could not be performed.” All this turned out to be the RD Gateway was not in the proper Active Directory Group, so added the server to the RAS and IAS Servers group.
Add URL to IIS
There was then an error about not being able to find the computer name, which turned out to be a setting in IIS. Looking under Sites > Default Web Site > RDWeb > Pages click on Application Settings and change the DefaultTSGateway to the URL of the CA external certificate for RemoteApps.
Fixing RS CAP & RAP
Last error that was received was the following:
Remote Desktop can’t connect to the remote computer “computername” for one of these reasons:
1) Your user account is not listed in the RD Gateway’s permission list
2) You might have specified the remote computer in NetBIOS format (for example, computer1), but the RD Gateway is expecting an FQDN or IP address format (for example computer1.fabrikam.com or 157.60.0.1).
This turned out to be related to the RD Client Access Policy (CAP) & Remote Access Policy (RAP) under the RD Gateway Manager tool and DNS. For RD CAP, make sure that Domain Users is listed, and that Client Computer Group membership is blank. FTor RD RAP, make sure that Domain Users is listed, and that it is set to allow connection to Any Network Resource (This allows remote access). For DNS, make sure it contains a Forward Lookup Zone that points to the URL of the CA external certificate for RemoteApps and has an A record for the internal IP address of the RD server.
If your company is currently moving some of your resources to the Azure cloud or wanting to properly setup your RemoteApps server, then contact us for assistance.
A series of recent security bulletins from Cisco, on February 2nd, detail an issue that has been discovered in several of their devices. Here is a summation:
Cisco ASA Security Appliances
FN-64228 : ASA 5506, ASA 5506W, ASA 5506H, ASA 5508, and ASA 5516 – these models all use the same clock signal part from the same vendor which has been found to degrade over time. After 18 months of continued operation this component will fail and cause the device to stop functioning, no longer boot, and will not be recoverable.
“Customers with affected products that are under warranty or covered by any valid service contract as of November 16, 2016 should go to the Clock Signal Component Issue page and follow the instructions in order to request replacements.” These replacements will be prioritized based on time in operation.
Meraki Router & Wireless APs
Meraki Notification – MX 84 & MS350 Series – these models all use the same clock signal part from the same vendor which has been found to degrade over time. After 18 months of continued operation this component will fail and cause the device to stop functioning, no longer boot, and will not be recoverable.
” Meraki will reach out to customers via email and on the dashboard to arrange replacement and the return of affected units.”
If your company is currently using one of the affected devices and have not heard from your current IT services provider about the replacement schedule, then contact us for assistance.
And God will generously provide all you need. Then you will always have everything you need and plenty left over to share with others. As the Scriptures say,
“They share freely and give generously to the poor. Their good deeds will be remembered forever.”
For God is the one who provides seed for the farmer and then bread to eat. In the same way, he will provide and increase your resources and then produce a great harvest of generosity in you. - 2 Corinthians 9:8-10
We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.
