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

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

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

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

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

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

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

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?