Endpoint Security

Why MSPs Should Expect No-Conflict Endpoint Security

“Antivirus programs use techniques to stop viruses that are very “virus-like” in and of themselves, and in most cases if you try to run two antivirus programs, or full endpoint security suites, each believes the other is malicious and they then engage in a battle to the death (of system usability, anyway).”

“…running 2 AV’s will most likely cause conflicts and slowness as they will scan each other’s malware signature database. So it’s not recommended.”

The above quotes come from top answers on a popular computer help site and community forum in response to a question about “Running Two AVs” simultaneously.

Seattle Times tech columnist Patrick Marshall has similarly warned his readers about the dangers of antivirus products conflicting on his own computers.

Historically, these comments were spot-on, 100% correct in describing how competing Endpoint Security solutions interacted on endpoints. Here’s why.

The (Traditional) Issues with Running Side-by-Side AV Programs

In pursuit of battling it out on your machine for security supremacy, AV solutions have traditionally had a tendency to cause serious performance issues.

This is because:

  • Each is convinced the other is an imposter. Antivirus programs tend to look a lot like viruses to other antivirus programs. The behaviors they engage in, like scanning files or scripts and exporting information about those data objects, can look a little shady to a program that’s sole purpose is to be on the lookout for suspicious activity.
  • Each wants to be the anti-malware star. Ideally both AV programs installed on a machine would be up to the task of spotting a virus on a computer. And both would want to let the user know when they’d found something. So while one AV number one may isolate a threat, you can bet AV number two will still want to alert the user to its presence. This can lead to an endlessly annoying cycle of warnings, all-clears, and further warnings.
  • Both are hungry for your computer’s limited resources. Traditional antivirus products store static lists of known threats on each user’s machine so they can be checked against new data. This, plus the memory used for storing the endpoint agent, CPU for scheduled scans, on-demand scans, and even resource use during idling can add up to big demand. Multiply it by two and devices quickly become sluggish.

Putting the Problem Into Context

Those of you reading this may be thinking, But is all of this really a problem? Who wants to run duplicate endpoint security products anyway?

Consider a scenario, one in which you’re unhappy with your current AV solution. Maybe the management overhead is unreasonable and it’s keeping you from core business responsibilities. Then what?

“Rip and replace”—a phrase guaranteed to make many an MSP shudder—comes to mind. It suggests long evenings of after-hours work removing endpoint protection from device after device, exposing each of the machines under your care to a precarious period of no protection. For MSPs managing hundreds or thousands of endpoints, even significant performance issues can seem not worth the trouble.

Hence we’ve arrived at the problem with conflicting AV software. They lock MSPs into a no-win quagmire of poor performance on the one hand, and a potentially dangerous rip-and-replace operation on the other.

But by designing a no-conflict agent, these growing pains can be eased almost completely. MSPs unhappy with the performance of their current AV can install its replacement during working hours without breaking a sweat. A cloud-based malware prevention architecture and “next-gen” approach to mitigating attacks allows everyone to benefit from the ability to change and upgrade their endpoint security with minimal effort.

Simply wait for your new endpoint agent to be installed, uninstall its predecessor, and still be home in time for dinner.

Stop Wishing and Expect No-Conflict Endpoint Protection

Any modern endpoint protection worth its salt or designed with the user in mind has two key qualities that address this problem:

  1. It won’t conflict with other AV programs and
  2. It installs fast and painlessly.

After all, this is 2019 (and over 30 years since antivirus was invented) so you should expect as much. Considering the plethora of (often so-called) next-gen endpoint solutions out there, there’s just no reason to get locked into a bad relationship you can’t easily replace if something better comes along.

So when evaluating a new cybersecurity tool, ask whether it’s no conflict and how quickly it installs. You’ll be glad you did.


This article was provided by our service partner : webroot.com

How to create a file server cluster with Windows 2019

High Availability of data and applications has been an important topic in IT for decades. One of the critical services in many companies is the file servers, which serve file shares where users or applications store their data. If the file server is offline, then people cannot work. Downtime means additional costs, which organizations try to avoid. Windows Server 2019 (and earlier versions) allow you to create highly available file services.

Prerequisites

Before we can start with the file server cluster configuration, the file server role must be installed and permissions must be set in Active Directory for the failover cluster computer object.

There are two ways to install the file server role on the two cluster nodes:

  • Via the Add Roles and Features Wizard of the server manager
  • Via PowerShell

In Server manager, click Add roles and features and follow the wizard. Select the File Server role and install it. A reboot is not required.

server 2019 cluster 1

As an alternative, you can use the following PowerShell command to install the file server feature:

Install-WindowsFeature -Name FS-FileServer

server 2019 cluster 2

To avoid errors at later steps, first configure Active Directory permissions for the failover cluster computer object. The computer object of the cluster (in my case, WFC2019) must have the Create Computer Objects permissions in the Active Directory Organizational Unit (OU).

If you forget about this, the role will fail to start later. Errors and event IDs 1069, 1205 and 1254 will show up in the Windows event log and failover cluster manager.

Open the Active Directory Users and Computers console and switch to Advanced Features in the View menu.

server 2019 cluster 3

Go the OU where your cluster object is located (in my case the OU is Blog). Go to the Security tab (in properties) and click Advanced.

server 2019 cluster 4

In the new window click Add and select your cluster computer object as principal (in my case WFC2019).

server 2019 cluster 5

In the Permissions list select Create Computer objects

server 2019 cluster 6

Click OK in all windows to confirm everything

Configure the file server cluster role

Because all pre-requisites are now met, we can configure the file server cluster role. Open the Failover Cluster manager and add the role to your cluster (right-click on Roles of your cluster -> configure role -> and select the File Server role).

server 2019 cluster 7

We will create a file server for general use as we plan to host file shares for end users.

server 2019 cluster 8

In the next step we define how clients can access the file server cluster. Select a name for your file server and assign an additional IP address.

server 2019 cluster 9

Use the storage configured earlier.

server 2019 cluster 10

After you finish the wizard, you can see the File Server role up and running in the Failover Cluster Manager. If you see errors here, check the create computer objects permissions described earlier.

server 2019 cluster 10

A new Active Directory object also appears in Active Directory Users and Computers, including a new DNS entry

server 2019 cluster 11

Now it’s time to create file shares for users. You can right-click on the file server role or use the actions panel on the right hand side.

server 2019 cluster 12

I select the SMB Share  Quick as I plan a general purpose file server for end users.

server 2019 cluster 13

I also keep the default permissions because this is just an example. After you have finished the wizard, the new file share is ready to use.

In the following video I show the advances of a continuous available file share. The upload of the file will continue even during a cluster failover. The client is a Windows 10 1809. I upload an iso to the file share I created earlier. My upload speed it about 10-20Mbit/s WAN connection. During failover to a different cluster node, the upload stops for some seconds. After successful failover it continues uploading the ISO file.

Next steps and backup

As soon as the file server contains data, it is also time to think about backing up the file server. Veeam Agent for Microsoft Windows can back up Windows failover clusters with shared disks. We also recommend doing backups of the entire system of the cluster. This also backs up the operating systems of the cluster members and helps to speed up restore of a failed cluster node because you don’t need to search for drivers, etc. in case of a restore.

 


This article was provided by our service partner : Veeam