SC Magazine has just published a five-star review of ZENworks Endpoint Security Management. The review gives ZENworks solution top marks for features, performance, support, value and documentation. Scoring the highest overall ratings possible, ZENworks offers a well-rounded solution with good bang for the buck.

Recently I joined the Product Management team within the Systems and Resource Management Business Unit at Novell. As part of this role I will become more active on Novell blogs sharing details of up and coming releases and best-practice materials.

In recent months, I’ve been very busy working with ZCM. In the coming weeks and months I will start sharing my war stories here. To start with though, I built my ZCM demo server from scratch yesterday. It’s a bog standard 10.0.2 server but has a NAT’d connection to the Internet. After opening up TCP …

It’s that time of year again, so I’ll be off to Salt Lake City. This year I only have one session, it’s a Tutorial but I am aiming to keep it as open and flexible as possible. Hope to see some of you there, details below:

Recently I’ve been busy working with customers to implement ZENworks Configuration Management (ZCM). My posts in the coming days and weeks will discuss the key points when considering a ZCM deployment.

So let us start with a couple of fundamentals, what do we really need to be in place before we start anything.

DNS
Forward and reverse lookups must be functional to and from all severs and workstations. We use forward and reverse look-ups in our certificate operations such as when a device checks in, when we hook into Casa for eDir/AD operations, and remote control operations.

Time Synchronisation
All managed devices, primary servers and the DB server should be sync’d as close as possible. Certain operations in ZCM are session based and therefore rely on accurate time between the two parties.

If you have any ideas on subject matter, please feel free to leave feedback.

Following on from Ron’s post on “green” data-centres, I thought I would share some thoughts from a desktop point of view. As the price of energy consumption rises, many organisations I have visited are considering new ways of working and managing user devices. Check out the Carbon Trust website, it makes interesting reading.

One popular question is “Should desktop machines be powered off automatically outside of normal working hours?”. I’ve spoken to a number of customers who believe that most of their users leave their desktop machines powered on overnight and at weekends. One approach to combat this is to publish guidelines and codes of practice for the user population. Another more direct approach is to use a management tool to ensure that desktops are shutdown when they are not needed.

So how can ZENworks help? ZENworks can be used to automatically power-off managed devices using scheduled actions and/or NAL applications that run utilities such as shutdown.exe. The Wake On LAN technology shipped with ZENworks allows groups of machines to be remotely powered on for lights-out distributions. I frequently see customers using this functionality to update devices in bulk during the course of a weekend.

Automatically powering off devices needs to managed very carefully though. Hell hath no fury like a user that has lost his or her data, even if they neglected to hit the save button.

What are your thoughts on desktop energy consumption? Are you using ZENworks today to help manage this more effectively?

Software Applications
These are applications that ZAM has prior knowledge about. The ZAM agent intelligently scans devices looking for known footprints of applications or suites of applications. Novell offer an monthly update to this footprint data via a Product Recognition Update (PRU) system. However, there will always be applications installed on devices that ZAM has no prior knowledge of. A good example of this is applications that have been developed in-house by your own developers. To manage these types of applications, ZAM provides a second option.

Software Files
ZAM can be configured to scan on a purely file-by-file basis looking for files with a “.exe” extension, in-fact any extension can be specified. ZAM will read everything it can about the file, such as Vendor, Version, Size and Date/Time stamp. This information is uploaded to the ZAM database in a Files Not Identified (FNI) list. Administrators can then choose to ignore entries in the FNI list or categorise the entries as Local Products.

A quick word of warning. Setting the option to collect information about all “.exe” files on all devices at once can lead to an extremely cumbersome FNI list. I’ve seen FNI lists as big as 500,000. If you’re thinking about using FNI, this is a simple approach that should make life easier.

Identify areas of the business where devices will have different product sets installed, for example:

Departments
Home workers
Laptop Users
VPN users
Administrative Users

Create a separate option set to collect FNI data and apply it to a handful of devices in each of these areas

Manage your FNI list by ignoring files and folders that are of no interest to your business

Categorise the remaining FNI entries as Local Products

Repeat steps 1-4 gradually expanding the target device list

Finally, if you want a specific application to be added to the next Product Recognition update, follow these steps.

ZENworks Patch Management (ZPM) is a relatively easy product to architect and deploy, the main challenges are around best practices for using the product day to day. Questions that need to be answered include:

What is the best way to schedule my patch operations?
What is the best way to handle patches that require reboots?
What business processes should be in place to ensure effective patching?

Mandatory Baselines
Well, let’s start with Mandatory Baselines. This functionality allows you to define a patch level, or list of vulnerabilities, that must be met by the targeted devices. ZPM automatically ensures that devices are patched to the desired level. I tend to avoid using Mandatory Baselines for production desktops as there is no easy way of scheduling when patching occurs. For example, if you install a product that back-revs a DLL and enables a previously patched vulnerability, on the next check-in the device could be patched again.

One approach is to use the “hours of operation” setting to prevent patching from occurring during normal working hours, this approach does minimise the impact on users but does have some drawbacks. Firstly, desktops and laptops are often not available outside of normal working hours, a lot of customers I visit encourage users to shutdown at the end of the day due to reduce energy consumption. More importantly, if I prevent patching during normal working hours, how do I deploy a patch in the event of a destructive virus?

Mandatory Baselines are useful in scenarios where you want to manage a standard build. Let’s assume for a moment that you are using a standard desktop image that is deployed to multiple machines. Adding your source machine for the build to a mandatory baseline will allow the device to be patched automatically before you seal the image for distribution. In this scenario, availability of the device and the requirement for rebooting is not an issue.

Do you use mandatory baselines? What approach do you take?

Testing and documentation
As with any software delivery mechanism, testing and release management is critical to minimising the impact on your business. A summary for a typical approach to managing patch delivery is as follows:

Identify new vulnerability

Analyse risk and exposure to the enterprise

Create deployment plan

Test deployment

Phase deployment to the enterprise

Each of these stages are normally documented to provide an audit trail.

Often I see customers deploying to test machines, then to the IT department and then phasing the deployment to the rest of the enterprise. What’s your approach to testing and deploying patches?

Every time I work on ZENworks Asset Management (ZAM), one of the first things that is requested is “How can I get more meaningful information about my business into the system?” Out-of-the-box reports can be grouped by items such as Domain, Default Gateway and Inventory Type, but customers normally want to see their Sites and Departments in reports.

Well, one option is to enter the data manually into the database using the ZAM Manager. This is not a popular approach for obvious reasons.

Another approach is to use the Collection Editor to display during a scan and ask the user to provide the information. Again this method is not popular as administrators tend to avoid using pop-ups on their users and users aren’t generally trusted enough to provide accurate data. So how can we automate this with ZENworks?

The Collection Editor can be configured to run silently to populate database fields with registry values stored on the device being scanned. In the example below, I am using two registry keys to populate the Site and Department fields.

Another important point to note; if you set the “Run Collection Editor” option to “Never” as shown below, the Collection Editor will still run silently to collect the values.

Now all I need to do is ensure that the registry keys exist on each and every device I want to scan. If your eDirectory is structured geographically and you are running ZENworks Desktop Management, you can create simple Application Objects to deploy the registry keys. If a workstation object moves to a new site, the local application will run and ZAM will update itself during the next scan.

I was at a customer last week that stores department, site and owner in the registry for every device as part of their standard build process. ZAM was able to pick up these values automatically allowing the customer to group reports exactly how they wanted to.

Do you run site based reports? How do you maintain your fields in your ZAM database?