Video Screencast Help

Cannot import ESM policy from another manager

Created: 25 Feb 2009 • Updated: 21 May 2010 | 9 comments
chungkc's picture

Hi,

 

I am facing a problem with importing a policy created in another manager.  When I tried importing the policy using the policytool, I got the following error:

>> The manager does not have a high enough SU level: o

 

My ESM Manager is running ver 6.5.3 SP2.  I have a content license, and when I run Liveupdate, it tells me that I am at the latest version, and there is nothing to be updated.  How come I get the above error message if this is so?

 

Pls advise, thks!

 

Rgds,

KC

Discussion Filed Under:

Comments 9 CommentsJump to latest comment

Rupali Korde's picture

Hi,

 

This error comes when the Source Manager has the higher SU level than the target manager.

 

When you are importing a policy on the target manager if there is any check in that policy which is not present in the module information of the target manager, it throws an error which you are getting.

 

You need to have the the same or higher SU level than the source manager to import the checks.

 

Can you please let me know the SU levels of the source and target manager both?

 

Regards,

-Rupali

chungkc's picture

The source manager is at SU35, according to the deployment team at the other side. 

 

On my side, I have not applied any SUs yet.  I started installing ESM 6.5.3 base, then upgraded to SP2.  When I clicked on properties of the manager, it just shows version as "6.5.3 SP2", no indication of SU level at all.

 

That is my predicament, I don't know what SU level I am at now.  How should I proceed from here?  

 

Thks and rgds,

KC

Rupali Korde's picture

Hi,

 

ESM 6.5.3 SP2 by default gives SU 2250.

 

You can register an agent having SU 35 to the ESM manager. This will upgrade the SU level on the manager to SU 35. Then try to import the policy.

 

Let me know if this helps/ doesnt help.

 

Regards,

-Rupali

chungkc's picture

I haven't had the chance to try out your suggestion yet, but will keep you updated when I have done it.

 

By the way, I was told that I can force the import of policies (regardless of whether the SU levels on source and target managers are different or not) by using the "-y" and "-force" options when using the policytool.  Is this true, and if so, what implications will there be (if any)?

 

Your professional advice is much sought after, thks!

 

Rgds,

KC

Rupali Korde's picture

Hi,

 

You can use -force option so that the missing checks will be discarded while importing the policy. The impact is, the checks in the source policy and the checks in the target policy will differ.  (Target policy will have less checks). Even if in future you upgrade the SU on the target manager to SU 35, those checks will be unavailable in the target policy as that policy will not be updated.

 

But if that is fine with you, you can go ahead and use that option.

 

Regards,

-Rupali

 

 

chungkc's picture

Ok, thks for the clarification! Will need to be careful when using the -force option, I guess.  But what about the -y option, what does that do?  Also, do you have any documentation that describes the policytool in more detail?

 

I will try to go onsite asap and try out your suggestion and see if it works.

 

Thks,

KC

Rupali Korde's picture

Hi,

 

Whenever there is any conflict during the execution of the policy tool (Policy with the same name already exist/ File with teh same name present) user is prompted with yes/no options to check whether he/she wants to go ahead.

If you donot want these prompts and the answer to all the conflicts is 'Yes, go ahead', you can use -y option.

 

This option is not going to solve the problem (missing checks) which you are facing.

 

You can get this information in User guide.

Chapter - Using the Symnatec ESM Utilities

Section - About the options for the policy tool

 

Regards,

-Rupali

chungkc's picture

I tried installing ESM on my own VMWare test image, and using the customer's content license, I managed to get content updates.  I could then import customer's policies without any issue.

Back at the customer's place, I tried reinstalling the ESM on a development server that had only a base Windows 2003 Server installed, and the Liveupdate worked too.

Our guess is that, on the production ESM server, the OS already came pre-imaged with SAV in Managed mode, which had Liveupdates pushed down to them, instead of the clients connecting out.

How do you solve this Liveupdate issue?

Rupali Korde's picture

 

 

Hi,
 
I don’t think these is any problem with Live update if you have ESM server on pre-imaged SAV machine because you can download the content packages only using ESM Console. Those will not get downloaded automatically.
 
Just go through following checks and let me know the result.
 
1.     Make sure latest SU contents are pushed on to the manager:
After downloading the LU contents on the console machine, you need to push them on the manager. When you get the message that you are at the latest SU level, check the <MANAGER_INSTALLPATH>\granularlu folder and <CONSOLE_INSTALLPATH>\ liveupdate\granularlu. If these are being pushed to manager from console properly, these contents should match for applicable OS.
 
2.     Make sure manager database (module.dat) has the latest contents/ checks:
You have the latest SU pushed on to the manager from console and you are getting ‘not
enough SU level’ error then -  Just check if you have the latest contents but those are not
pulled by agents and are not pushed back to manager’s CDB.
 
To update the manager database - Once you have downloaded the SU content, you have to run the policy on the agent. So that agent gets the latest contents. You have to re-register the agent to the manager so that manager CDB (module.dat) has the latest contents/ checks.
 
e.g. If manager is at SU 2250 (module.dat is at 2250), and you have pushed SU 3500 contents on the manager (granularlu folder has data of SU 3500) this doesn’t make the SU level of the manager as 3500. Consider that at this point agent is also at 2250. You have to run a policy on the agent so that these latest contents (SU 3500) are pulled by the agent and the policy has been run on the latest SU. This will make the SU level of the agent as 3500. After agent has got the latest SU contents, unless and until the agent is re-registered with the manager, manager’s CDB (module.dat file) will not get updated (those will still be 2250). So you have to re-register the agent.
 
Hope this helps.
 
Regards,
-Rupali