Management

 
 
By Andrew Garcia  |  Posted 2007-05-23 Print this article Print
 
 
 
 
 
 
 


Management We were somewhat disappointed with FCS disjointed management facilities, which for us fell short of the integrated, cohesive and simplified management experience for which Microsoft is aiming. Rather, as we moved back and forth between the management consoles for WSUS, Active Directory, MOM and FCS itself, we felt that we were straddling too many disparate applications for comfort. We hope to see FCS management story become better aligned as Microsoft moves to an MMC (Microsoft Management Console)-based approach for WSUS 3.0. However, the Forefront customer whom we interviewed during our review disagreed with this perspective. Kevin Hayden, desktop engineering manager for Analog Devices, indicated his team does not spend much time in the MOM console, for instance, except when trying to isolate an alert. According to Hayden, after initial setup and trials, Forefront management was a pretty simple, single-console affair. Whats more, Hayden told us the inclusion of MOM gives his staff a leg up on a client operations management project they have in the works.
eEye Digital Securitys Blink Professional 3.0 provides strong vulnerability assessment tools. Click here to read eWEEK Labs review.
Disparate management perspectives aside, one thing we can say for sure is that with all software components that FCS requires, administrators of the product will have to throw some significant hardware at their deployments. For a single-server configuration that hosts all elements of the FCS platform, Microsoft recommends at least a dual 2.85GHz CPU server with 4GB of RAM. FCS component prerequisites may be split among as many as six servers, separating out the reporting, collections, management and distribution server components as well as the reporting and collection databases. Like Hayden, however, we opted for a two-server setup, sing an existing WSUS 2.0 server while hosting all other elements on a single machine. Microsofts decision to use WSUS and Windows Automatic Update client to deliver both the client software packages and malware signatures seems to us an odd match to fit the needs of a signature-based security solution. A WSUS server is designed to synchronize with Microsoft Update servers only on a daily basis, and Automatic Updates is designed to install software only once a day. During tests, we found Microsoft released new signature files between three and six times a day, so WSUS and Automatic Updates—at least in their default configurations—fall short. Fortunately, Microsoft has addressed these shortcomings by providing a component for installation on the WSUS server that bumps synchronization frequency to once per hour. Along similar lines, FCS client software component triggered more frequent update checks. Companies that have chosen a third-party patch delivery system will likely be loath to install and maintain WSUS on top of their existing systems, not to mention re-enable Automatic Updates on their clients. Microsoft does offer signature file downloads from its Web site, and these files can be installed manually or with a script. However, this is hardly an ideal solution given the frequency of signature updates. Moving forward, we expect to see third-party patching vendors offer scripts or other mechanisms to automate this process for their own customers, which would make life easier for companies out to mix FCS with non-Microsoft patching products. During tests, we configured FCS updates by visiting the WSUS console, enabling WSUS synchronization, and approving the signature files and FCS client installation package to push out to our Windows endpoints. We also configured WSUS to automatically accept, download and deploy future updated signature files. Before we could begin deploying FCS components to our clients, we had to visit a separate interface, the FCS Management Console, to create a security policy to govern the process. FCS security policies allowed us to centrally control whether to engage anti-virus or anti-spyware defenses, enable heuristic detections, schedule scan times, or create exemptions (either file folders or file types). We could also schedule periodic security-state assessments, providing a Baseline Analyzer-type scan to look for missing patches, unnecessary services or passwords susceptible to compromise. After wed created our policies, we were ready to deploy them via Active Directory. From the FCS console, we assigned one of the policies wed drafted to a Security Group or an Organizational Unit, which triggered the creation of a new GPO (Group Policy Object) consisting of a number of specific registry changes, which FCS then automatically linked to our targeted Active Directory object. We could also assign the FCS policy directly to an existing GPO, or we could copy it to a file for manual distribution using FCS command-line policy distribution tool. Next Page: Reporting.



 
 
 
 
Andrew cut his teeth as a systems administrator at the University of California, learning the ins and outs of server migration, Windows desktop management, Unix and Novell administration. After a tour of duty as a team leader for PC Magazine's Labs, Andrew turned to system integration - providing network, server, and desktop consulting services for small businesses throughout the Bay Area. With eWEEK Labs since 2003, Andrew concentrates on wireless networking technologies while moonlighting with Microsoft Windows, mobile devices and management, and unified communications. He produces product reviews, technology analysis and opinion pieces for eWEEK.com, eWEEK magazine, and the Labs' Release Notes blog. Follow Andrew on Twitter at andrewrgarcia, or reach him by email at agarcia@eweek.com.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Rocket Fuel