|Introduction|||||How we tested|||||PCE|||||Verdict|
Most companies have an AUP (Acceptable Use Policy), which prohibits using company resources for unacceptable purposes. Yet enforcing the acceptable use of business computers is quite often a tricky business.
Depending on the business and its user base, the AUP can be quite relaxed, only forbidding more extreme behaviour like accessing pornographic Web sites or disseminating threatening e-mails (essentially, any behaviour which could lead to legal action). At the other end of the scale are businesses which forbid their users to indulge in using computers for any personal, non-work-related activities.
There are various methods of policy enforcement, some more effective than others. Very common methods are user/workstation group policies applied on login and Web content filtering at the firewall/proxy level. These approaches are generally easy to implement as the infrastructure supporting them is generally already in place, so it's just a natural extension of pre-existing services. They are a bit reactionary however, placing the onus of enforcement on the IT services department. This means thinking ahead of their user base, attempting to -head them off at the pass", so to speak.
A better approach is to place the onus back onto individual users, and have them police themselves. Rather than having the AUP Police stand over everyone's shoulder while they work, to make such an approach effective means you need a physical presence at each workstation with centralised data collection. This is where applications like Policy Central Enterprise come into their own.
The main server application is installed on a machine running Windows 2000/XP Professional or Windows 2000/2003 Server. Data is stored on either a local MDSE/SQL 2005 Express database, or a local or remote SQL 2000/2005 database. The PCE application can only install to a database server which does NOT use a named database instance. While many SQL-based applications can install to a named instance if specified in full, PCE won't recognise the database. The front end is accessed via a virtual Web site served by IIS 5.0 or 6.0. .NET Framework 1.1 or 2.0 is also a requirement on the server machine.
The operating system requirements are dependent on the size of the client base that PCE will be supporting. For a small network of up to 35 clients, Windows XP Professional with an MSDE/SQL 2005 Express database is fine. Bear in mind that Windows XP Professional only supports a maximum of 10 concurrent connections, so for more than 10 clients Windows 2000/2003 Server is required. Subsequently, anything more than 500 clients requires a local or remote SQL 2000/2005 database.
PCE can communicate with Active Directory (AD) to import users, groups and machine information into its own database. The machine which PCE is installed on does not have to be a member of the AD domain but it helps with the speed of communication (especially if AD is heavily populated).
The client component of PCE is installed on every machine in the organisation -- which is what enables system administrators to maintain a physical presence at each workstation. The client software has a very small footprint -- around 200KB -- and is completely undetectable. It communicates back to the PCE server on non-standard TCP/IP ports to avoid conflict with other networked applications.
The PCE server maintains a list of attached clients, and distributes the centrally-maintained policies to each. The client software monitors local activity and when it detects an action which violates the policy, or is in some other way actionable, an event is created and logged with the PCE server. The server documents the event for that particular user, and can automatically inform the system administrator via SMTP.
There are currently no prices available for this product.