Any reasonable antispyware product has some way to centrally
manage all clients–even into the tens of thousands of clients, and has a small
footprint for the actual client software as well as a reasonable definition
distribution system. Webroot’s SpySweeper Enterprise 2.5 has all of these
features and more. In this article, I will show you how to get this product up
and running and managing clients in your organization.

System requirements

Even supporting tens of thousands of clients, you don’t need
a very hefty server to run SpySweeper Enterprise. Overall, the system
requirements are quite modest, and Trend Micro even provides a database product
for smaller shops so you can avoid SQL Server licensing costs.

Workstation

SpySweeper Enterprise supports quite a few operating
systems, including some older software no longer supported by its competitors.
Spy Sweeper 4.5 supports all workstation versions of Windows back to Windows 98
SE. Webroot requires that you have a minimum of a 300MHz processor, 128MB of
RAM and 30MB of available disk space to handle the client. 256MB of RAM is
preferred, though.

Server

Webroot’s SpySweeper Enterprise 2.5 does not require a
massive server to do its job. In fact, Webroot’s minimum requirements call for
only a 200MHz server with 512MB of RAM, although Webroot does indicate that
200MHz is the minimum and recommends a machine that runs at least 350MHz. These
days, that’s one of the machines you took off a user’s desktop and used as a
doorstop.

If you plan to support more than a few users, I would highly
recommend that you invest in a reasonable machine of at least 1GHz. Further,
Webroot recommends that you have at least 60MB to 140MB of free disk space for
the initial installation, with a gig or two available for growth. In the
scalability section, I’ve listed more exact server requirements for those
of you that may have more than 500 clients.

Webroot’s server also requires a database component in order
to work its magic. While you can use an existing Microsoft SQL Server 2000
installation, you can also use the DBISAM database that is included with
SpySweeper Enterprise 2.5. If you use the included software, you don’t need to
worry about any licensing issues related to the database. That’s all taken care
of when you buy SpySweeper Enterprise.

Scalability

While SpySweeper Enterprise is capable of handling large
numbers of clients from a single server, Webroot has taken the issue of
scalability seriously in their product. For example, suppose that you need to
support tens of thousands of desktops strewn about dozens of locations. Using
what Webroot calls “Distribution Servers”, which you can place in
each location, you can more easily and affordably support just about as many
clients as you can throw at the product.

A distribution server is a single server in any location
that receives its updates from the central enterprise server. Clients are then
updated from the distribution server rather than having to connect back to the
central server. This type of scenario helps you better manage inter-site
bandwidth and support larger numbers of clients.

During the server installation, you will be asked to select
which database you want to use to store information for your SpySweeper
Enterprise service–DBISAM or SQL Server 2000. Webroot recommends that you only
use SQL Server 2000 if you have more than 10,000 clients running from your
SpySweeper server and that, of course, you actually own SQL Server 2000.
Otherwise, they recommend that you use the DBISAM option. If you select the SQL
Server 2000 option, you will need to manually create a database for SpySweeper
to use.

Table A
View Table A
Minimum specifications based on number of clients in your environment

Webroot provides recommendations for how much horsepower
your server should have an on how many distribution servers you should plan
based on how many clients you intend to support. Table A outlines these
recommendations. Bear in mind that these are the minimum specifications.

Installation

The SpySweeper Enterprise 2.5 installation process follows a
fairly typical client/server installation scenario. Your first task is to get
the server deployed. In this case, the server hold the SpySweeper management
console, from where you can centrally manage your antispyware rollout. In my
opinion, installing any enterprise management software without some kind of
centralization is asking for a support nightmare.

Once the server component is in place, SpySweeper provides
you with a number of options for deploying the client to your workstations. All
of the methods use a standard MSI installation file. You can push the client
installation from the management console, install from a login script or via an
Active Directory group policy, or deploy from a software distribution system,
such as SMS or ZenWorks. Or, you can just walk around with a CD and install the
client manually. If you have thousands of desktops, I don’t recommend this
method, unless you want to get out and about in userland for weeks at a time.

Before you begin the antispyware software installation

If you intend to use SQL Server 2000 as your database, you
need to manually create a database for SpySweeper as well as a related database
user. For this purpose, Webroot recommends that you use SQL authentication for
the user you create rather than relying solely on Windows authentication to the
database. Further, SpySweeper requires that you use case insensitive collation
on your SQL Server 2000 system.

To create this database, from whatever server on which you
have SQL Server installer, start SQL Server Enterprise Manager by going to
Start | All Programs | Microsoft SQL Server | Enterprise Manager. Once you are
in Enterprise Manager, make sure that your SQL Server supports both Windows
authentication and SQL Server logins. Go to Tools | SQL Server Configuration
Properties and select the Security tab to check this setting as seen in Figure
A.

Figure A
The highlighted area needs to be examined.

If you are currently set for Windows-only authentication,
change this option and click OK. When you do so, you will be told that SQL
Server must be stopped and started, but this happens automatically.

Now, expand the tree until you see the Databases option
under your server. Right-click the Databases option and choose New Database
from the shortcut menu as seen in Figure B.

Figure B
Choose New Database from the shortcut menu.

On the resulting Database Properties window, in the Name
field, enter the name of the database you want to create to use for SpySweeper.
In this example, I’ve given it the name ‘SpySweeper’. I know, not very
original. Once you enter a name, click OK as seen in Figure C.

Figure C
Give your database a unique name.

At this point, your new database is created, but you need to
create a SQL user so SpySweeper can access the database. Right-click your newly
created database and choose New | Database User from the shortcut menu. On the
resulting Database User Properties window, shown in Figure D, click the
drop-down button next to the Login name field, and choose the “New”
option from the menu as seen in Figure D.

Figure D
Choose the New option to create a new SQL user. We’ll add this user to the
new database soon.

The resulting SQL Server Login Properties window has a bunch
of option to which you need to pay attention you can as see in Figure E. First,
give your user a name. In this example, I’ve used the ever-original name ‘spyadmin’.
Choose the SQL Server Authentication option, and provide a password for this
user. Finally, one thing I like to do with SQL database users, when possible,
is assign them a default database. Click OK when you’re done. You will be asked
to confirm the password you’ve assign to this new user. If you did grant the
user the default database of SpySweeper, you may receive an error message
indicating that the user does not have access yet. Click Yes to continue past
and ignore this message for now. We’ll fix that next.

Figure E
Make sure you select the right properties to make your SpySweeper
installation go more smoothly.

Now, on the Database User Properties window, Figure F, click
the down arrow next to Login name and choose the database administrative user
that you just created, and make sure to assign this user the db_owner role so
that the user can make any modifications that it needs to make to the
SpySweeper database. Click OK when you’re done.

Figure F
Give your database administrative user a name.

You can close SQL Server Enterprise Manager now. I will use
this database during the installation of the SpySweeper product.

Server

For this article, I’m going to stick with a single
centralized server, and will not be installing any distribution servers. To
start the installation, run the file WebrootEnterpriseServerSetup.exe from your
distribution media or download.

As usual, the first couple of screens give you a quick
overview of the software, followed by the ever-present software licensing
agreements. Read each one, and click the Next button to continue.

Next, provide an installation path for SpySweeper
Enterprise. The default location is C:\Program Files\Webroot\Enterprise\Server,
which I have used for this example as seen in Figure G. If your chosen
directory doesn’t exist, the installation asks you if you really want to create
a new folder.

Figure G
If you want to choose a new path, click the ellipsis button to the right of
the installation path box and select a new installation location.

Now, in a not-so-important step, choose the Start Menu group
into which you want SpySweeper’s launch icons to be installed as seen in Figure
H.

Figure H
Into which Start Menu group do you want launch icons to be installed?

On the next screen, you start doing something that gets you
somewhere. First, the installer asks you for the name of your company. Second,
on the screen shown in Figure I, you’re asked to enter your keycode that
uniquely identifies what your installation is to do. Your keycode is sent to
you enclosed in { curly braces }. Make sure that, when you enter your keycode,
you include these curly braces. Click Next.

Figure I
Provide your company name and your keycode.

After your installation, the SpySweeper server needs to
occasionally poll Webroot central command in order to obtain updates, including
software updates and information regarding new spyware. Webroot recommends that
you don’t set this to be less than twelve hours, which is the installer’s
default period.

The reason: Webroot only releases updates on Tuesdays and
Thursdays, so polling their servers more often is generally a fruitless
endeavor. On this screen of the installer, Figure J, tell SpySweeper how often
you’d like it to poll for updates. Even though Webroot does not provide
constant updates, SpySweeper gives you a choice in the range from hourly to
weekly. With your polling period defined, also tell SpySweeper into which
directory updates should be stored. The default is C:\Program
Files\Webroot\Enterprise\Server\Updates. Click Next.

Figure J
How often should the software look for updates, and where should it store
said updates?

The next screen, Figure K, asks you to enter information
regarding your proxy server, if you have one. I don’t have a proxy server in my
lab, so I’ve left this screen blank. Click the Next button to continue.

Figure K
Enter proxy settings for your network, if required.

Like your server does with Webroot, each client needs to
periodically chat with your SpySweeper Enterprise Server to look for new
definitions and to see if you’ve made any configuration changes that may need
to be applied. In this polling scenario, the client, by default, polls the
server every hour. You can change this interval to be as short at 10 minutes,
or as long as a day. Also, provide the static IP address and IP port on which clients
can communicate with this server. If you’re using a software firewall on the
server, make sure to allow communication on this port. By default, SpySweeper
uses port 50,000 for this conversation. You can set these setting on the screen
shown in Figure L.

Figure L
Choose your client polling interval, and provide your server’s IP address
and desired IP communications port.

The SpySweeper server needs an SMTP server through which it
can send notification messages. Specifically, you need to provide the name of
an SMTP server, as well as a real email account, which SpySweeper will use as
the “From” address. For this example, I’ve created an email account
specifically for SpySweeper as seen in Figure M.

Figure M
Provide email settings for your organization

If your mail server requires that you authenticate in order
to send mail through, provide your credentials on the next screen, Figure N. In
my lab, I’ve allowed relay from my SpySweeper server (and only from this
server) to my SMTP server instead.

Figure N
If your mail server requires a login to send mail, provide those
credentials here.

When you deploy the client, do you want the user to see the
process? If not, you can run the client
installer either minimized, or even invisibly. These choices, plus the option
of popping up a window, are presented to you on the next screen of the
installer. For this example, Figure O, I’ve opted for the “Stay Minimized”
option.

Figure O
How shall the user at the client see the installation?

The next screen, Figure P, asks you to choose which database–DBISAM
or SQL Server 2000–you want to use for your installation. Webroot recommends
that you only use SQL Server 2000 if you have more than 10,000 clients running
from your SpySweeper server and that, of course, you actually own SQL Server
2000. Otherwise, they recommend that you use the DBISAM option. For this
article, I will be using the SQL Server 2000 database option. Of course, if you
have only a few (or a few thousand–up to 10,000, actually) clients, you can
use the included DBISAM database instead.

Figure P
Provide the database settings that match what you set up earlier.

The next screen asks you to verify your entries. Once you do
so, the installation begins. At the end of the installation, you are told that
you have a number of options for client deployment, including an automatic deployment
from SpySweeper’s console. Of course, you can also deploy the client via group
policy, Active Directory, SMS, or whatever method you would normally use. The
client installer (MSI) files are located at C:\Program
Files\Webroot\Enterprise\Server\Client.

Do note that the server installation installs only the
SpySweeper Enterprise console, and does not install a client. For this example,
I will install the client to the server using an MSI file and will push deploy
a client to a workstation using the management console.

Server MSI client installation

To install the client on your server, browse to the MSI
client installer location and double-click the file SpySweeperSetup.exe. That’s
all you have to do. The installation
is completely automatic beyond that. When you’re done, the SpySweeper icon will
appear in your system tray as seen in Figure Q.

Figure Q
Double-click the icon to open SpySweeper’s local console.

Centralized client deployment

Before you can deploy clients using SpySweeper’s push
feature, you need to configure the SpySweeper Admin Console service with the
credentials of a domain administrator. To do this, go to Start | Administrative
Tools | Services (Windows 2000: Start | Control Panel | Administrative Tools |
Services). Locate the service named Webroot Admin Console and right-click it,
choosing Properties from the resulting shortcut menu.

From the Properties page, select the Log On tab. On this
tab, choose the “This account” option and provide the credentials for
an account that has domain administrator privileges as seen in Figure R. Note
that Windows will add the “Log on as a service” right to this account
when you do this. Using Active Directory Users and Computers, I’ve created an
account named SpyAdmin and added it to the Domain Administrators group.

Figure R
Make sure the account has domain administrator rights so it can log into
any workstation.

You need to stop and restart the service once you make this
change.

Now, go to Start | All Programs | Webroot (Enterprise) |
Admin Console. The default username is admin, as is the default password for
the console.

In the Admin Console, choose the Client Deployment option.
Select the domain or workgroup that contains the system onto which you want to
deploy the client, and then look for the client in the right-hand window. It
may take a little time for this window to fully populate. Select your target
system and click the Deploy Client button located at the bottom of the window
as seen in Figure S.

Figure S
Automated deployment of a client can save you a whole lot of time!

Wait between 30 seconds and a minute and click the refresh
button. When you do so, you should have a green indicator with a check mark
next to your client as seen in Figure T and, if you look at one of your client
machines, you will see the SpySweeper icon sitting in the system tray. Even
better, with the exception of the icon appearing, the entire process is
transparent to the user.

Figure T
Deploying a SpySweeeper client is very, very easy and incredibly fast!

Managing clients

At this point, you have the management console installed and
working, and you’ve successfully deployed a client. Like any good enterprise
antispyware product, SpySweeper provides you with the capability to define
policies for different groups of computers. For example, you might want
computer A to do a full scan between 5 and 6 in the morning while computer B
should perform a scan sometime in the evening.

Adding groups

To add a new group into which you can place workstations, go
to Admin Tasks | Client Management and click the Add Group button. A box
appears asking you for the name of the new group. In Figure U, I’ve created the
group named ‘TR sample’. The group named ‘EXAMPLE’ was already there, and the
name was derived from the name of my domain (example.com).

Figure U
You can have any number of groups to support your organization.

To add a workstation to a group, drag and drop it from the
right-hand section of the screen into the group in which you want the client to
reside.

Managing group settings

Each group can have its own policies, including scheduling
scans, and determining what a client should do once spyware is found. To manage
group settings, in the admin console, go to Manage Desktop Applications | Spy
Sweeper | Configure Spy Sweeper | Schedule Sweeps. Take a look at Figure V.

Figure V
The same list of groups appears here.

Notice that there are two groups here that match what we
looked at before. However, there is also a top-level group here named ‘TR
example’. By default, this top-level group holds a global policy that can be
overridden by lower-level groups. In fact, the group TR sample uses its own
settings. You can tell by looking at the bold text that reads “Group ‘TR
sample’ uses group settings”. If I had not made any changes to TR sample’s
settings, that text would instead read “Group ‘TR sample’ uses company
settings”, which are the default settings that you establish for the top
level group.

Figure W, X and Y show you the other primary configuration
screen for centrally configuring the client side of Spy Sweeper. I won’t go
over every option in this article, but will show you the screens so you get a
feel for what SpySweeper can do.

Figure W
This is the “Sweep Settings” screen on which you can dictate
which drives the SpySweeper client will scan as well as other parameters,
including whether or not SpySweeper will scan memory and the registry and much
more.

Figure X
What would you like the SpySweeper client to do with the various kinds of
detected spyware?

Figure Y
Which “Smart Shields” would you like to enable? Webroot uses the term “Smart Shield”
to refer to a continuous, active monitoring activity.

Getting to the root of spyware

SpySweeper is a feature-packed product with just about all
of the components that make for a viable enterprise-grade antispyware service,
including central administration, an active scanning feature, and more.