Friday, December 16, 2011

Setting up an account for the antivirus agent on a NetApp

When you install an antivirus server like Trend Micro ServerProtect or McAfee VirusScan Enterprise for Storage or a backup agent (such as HP Data Protector) and you want to plug them on your NetApp, there is one action which is necessary to allow the Trend or ePO agent to communicate with the filer.

This action is to set up a user account which can bypass file security to scan or backup the shared files wherever they are stored on the NetApp qtrees.

So, the first step to accomplish this action is to create an Active Directory user account named yourdomain\youravuser (if you don't have one already). Then you have to add yourdomain\youravuser to the local backup operator group on the NetApp.

The commands to use are shown below.

Tuesday, December 13, 2011

Celebrating 20 years of Linux

I'll be celebrating 20 years of Linux with
The Linux Foundation!

Understanding Windows Services Recovery features

As you probably know Windows has the ability to automatically perform some predefined action in response to the failure of a Windows Service. The Recovery tab in the Service property page let you in fact define the actions that the system has to perform on first failure, second failure, and subsequent failures.

Valid options are "Take No Action", "Restart the Service", "Run a Program", and "Restart the Computer".

In my case I have configured my test Trend ServerProtect service to restart after the first and the second failure, then a system reboot is executed the next time this service fails.

To test this I have written a basic batch script which recursively kills the service. Doing so I have just discovered that, with the default setting, Windows always performs the action defined for the first failure (in my case my TREND ServerProtect test service is restarted) and will never go through successive actions.

Furthermore I see that the event log reports all the time the same diagnostic message, even in case of recurring service failures:

Log Name:      System
Source:        Service Control Manager
Date:          07/12/2011 10:54:25
Event ID:      7031
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      servername
Description:
The Trend ServerProtect service terminated unexpectedly.  It has done this 1 time(s).  The following corrective action will be taken in 60000 milliseconds: Restart the service.


The "It has done this 1 time(s)" sentence looks problematic to me because I am recursively killing this service and the failure counter should increase.

If I double check the recovery parameters with sc.exe I am happy with the output:

sc qfailure spntsvc
[SC] QueryServiceConfig2 SUCCESS

SERVICE_NAME: spntsvc
   RESET_PERIOD (in seconds)    : 0
   REBOOT_MESSAGE               :
   COMMAND_LINE                 :
   FAILURE_ACTIONS              : 
     RESTART -- Delay = 60000 milliseconds.
     RESTART -- Delay = 60000 milliseconds.
     REBOOT -- Delay = 60000 milliseconds.

So, why does the failure counter does not increase? Cleary it looks like there is a bug in the way the Service Control Manager reads or understands the parameters I have set.

After deep investigation, and a after many searches throughout technet.microsoft.com, I found that setting the "Reset fail count after:" option to 0 means that the failure counter will not be stored at all. So I completely misunderstood its meaning. At first I was lost for words when I discovered that this parameter did not do what I expected from it.

Anyway, once you know that keeping this option set to 0 disables both the "second failure" and "subsequent failure" actions, the solution is pretty simple: set its value to 1 (or whatever you like) and you'll get the desired behavior upon service failure (in my case the server will restart upon third failure).

I hope this post will help you and, if so, do not hesitate to comment!

Friday, December 2, 2011

VMware vMotion and the CPU incompatibility problem

By default, VirtualCenter only allows migrations with vMotion between compatible source and destination CPUs. So if you have been trying to move a VM from one host to another, and you got stuck with a error message telling you that the CPU of your destination host in incompatible with the CPU configuration of your Virtual Machine, then this usually means one of the following:

a) you did not mask the NX/XD bit in the settings of the VM or...
b) you did not enable the "No-Execute Memory Protection" on both your source host and destination host or...
c) you did not have your cluster of ESX hosts configured for Enhanced VMotion Compatibility (EVC)

The complete error message you get is:

CPU of the host is incompatible with the CPU feature requirements of virtual machine;
Problem detected at CPUID level 0x80000001 register edx 



There are different methods to get past this blocking point.
Related Posts Plugin for WordPress, Blogger...