aphilp's blog

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?

The process of discovering applications in ZENworks Asset Management (ZAM) can be broken into two areas:

1. 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.
2. 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.

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

   Departments
   Home workers
   Laptop Users
   VPN users
   Administrative Users

2. Create a separate option set to collect FNI data and apply it to a handful of devices in each of these areas
3. Manage your FNI list by ignoring files and folders that are of no interest to your business
4. Categorise the remaining FNI entries as Local Products
5. 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.

Do you use FNI lists? What types of files do you track?

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:

1. Identify new vulnerability
2. Analyse risk and exposure to the enterprise
3. Create deployment plan
4. Test deployment
5. 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. :D

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?

Written at: Frankfurt, Germany

My name is Andy Philp and I am a ZENworks specialist working in Novell Consulting UK. For the past 4 years or so, I have worked with many customers across Europe architecting, designing and implementing solutions with all of the ZENworks products.

So why I am on Cool Blogs? Well, I’m very passionate about ZENworks and want to hear from you directly regarding your experiences, good or bad, so we can learn from each other. Over the coming weeks and months I'll be sharing my experiences and posting tips and tricks to help you maximise your ZENworks experience.

I hope you find my future posts informative and useful.

Written at: Frankfurt, Germany

When you install ZENworks Configuration Management, one of the first choices you are asked to make is whether to use an internal or external Certificate Authority.

The managed agent uses .NET code to communicate via TLS with the ZCM server. Installation of the managed agent automatically updates the client's local machine trusted root authority certificate store with the the CA (Certificate Authority) of the server.

The main sticky points I see with DNS are making sure that the URL used to connect to the Primary Server is the same DNS name as the server itself. So long as the CA has signed the cert of the primary server (performed during the Primary Server install) and the DNS name used to connect matches the servers cert exactly, all’s well with the world.

If you want to connect using different IP/DNS names, such as in a NAT environment, they are ways around those problems. Firstly, you can populate “Additional DNS names” and “Non-detectable IP addresses” to tell the primary server about other connection methods. Secondly, you can tell the client to ignore name matching with a reg key. Is that what you went with?