10.0.5520 breaks previous hotfix

[Fernando_Vinan-]

I upgraded from 5484 to 5520 and it's broken at least one hotfix, number 7 (Modifying the backup method causes jobs to rerun; Importing templates within a policy will modify the schedule of all templates in that policy) http://seer.support.veritas.com/docs/275166.htm.

I've compared the files replaced by the original hotfix against the 5520 versions and they're all now 5520.

[Ajit_Kulkarni]

Hello,

In Backup Exec v10.0 Rev5520, the hotfix 7 of Backup Exec v10.0 Rev5484 is integrated. You may like to see the release note for Backup Exec v10.0 Rev5520. The link is mentioned below:

Release Notes for VERITAS Backup Exec (tm) 10.0 for Windows Servers revision 5520
http://support.veritas.com/docs/276379

I would like to know the meaning of the first sentence of your post "I upgraded from 5484 to 5520 and it's broken at least one hotfix, number 7"

Regards

NOTE : If we do not receive your reply within two business days, this post would be marked "assumed answered" and would be moved to "answered questions" pool.

[Fernando_Vinan-]

Yes I realise that the hotfix is for 5484, I can read.

My sentance means "I upgraded from 5484 to 5520 and the problem has come back" i.e. the hotfix 7 has been forgotten in 5520 (as far as I can tell anyway).

I tried to set up multiple jobs in a policy by importing a similar template and every time I changed the scheduling in the new job, the schedule changed to the same for the original template.

In the end I deleted the policies and created individual jobs which at least I can control

[Deepali_Badave]

Hello,


we cannot vary the schedule to create multiple jobs using the same policy.

NOTE : If we do not receive your reply within two business days, this post would be marked assumed answered and would be moved to answered questions pool.

[Ryan_Russell]

I can confirm that 10.0.5520 broke hotfix number 7 for me as well. New templates can be varied in their schedules, but importing and changing one changes the other.

[Fernando_Vinan-]

> I can confirm that 10.0.5520 broke hotfix number 7
> for me as well. New templates can be varied in their
> schedules, but importing and changing one changes the
> other.


Thank-you. Obviously the half-wits that call themselves support have no idea about the product they're supporting!!!

[Neil_Goldstein]

Ajit,

I think what they are saying is that there is a regression in 5520 build.

Build 5520 has the BUG that was fixed in the earlier hotfix 7 on the earlier build.

Action items for you:
#1 Please submit this to Test Engineering for regression testing of patch7 bug on the 5520 build.

#2 )Please report back to us if Test Engineering can not duplicate since we can duplicate the problem in the field without difficulty.

Thank you,

-Neil

[Renuka_-]

Hello,


The evidence/logs would have to be examined personally by an engineer for further tests of that type to be done.


NOTE : If we do not receive your reply within two business days, this post would be marked assumed answeredand would be moved toanswered questions pool.

[Ryan_Russell]

Here is a five minute prove-up:

- create a new policy
- create a template with a specific schedule
- import that same template to create a copy of it within the same policy
- change the schedule on the new template
- verify that the original template has also changed its schedule

Your post says that evidence/logs have to be examined by an engineer. Is this a request for logs? If so, what logs should we send in?

[Neil_Goldstein]

Ryan,

Hopeful "Renuk a" will respond. The hard thing here is the job logs are not useful since the error occurring during administration, not during running of the job.

"Renuk a" or other Veritas Support person- can you please provide some guidance as to:

a) What logs should be collected for a problem that occurs when changing the schedule of a copied template within a policy? (That is the error occurs before a job even runs, so job logs are not relevant)

b) Where should these logs be delivered? Posted Here? Emailed to "Renuk a"?

Thanks,

-Neil

[Sharvari_Deshmu]

Hello,

Due to the complexity of your issue, resolution will require the personal attention of a VERITAS representative.
Please contact us through your local support number.You can see a list of support numbers at our support web site:

http://support.veritas.com/prodlist_path_phone.htm



Please note that you may be charged for this service.

For the latest details on pricing, please visit http://support.veritas.com/srv_portfolio/srvc_pricing_matrix.htm


Thanks,

NOTE : If we do not receive your reply within two business days, this post would be marked "assumed answered" and would be moved to "answered questions" pool.

[Neil_Goldstein]

Sharvari,

The problem that is under discussion is a regress of your internal Etrack# 288343 that is occurring with 5520 build (were 288343 was filed under the build 5484.

I see the Etrack info at this URL:
http://seer.support.veritas.com/docs/275166.htm

I don't see why this is so complex.

My customers are not running on 5520 yet - and because of this regression I can not upgrade them either. This of course makes the phone call a bit tricky.

-Neil

[Fernando_Vinan-]

I suspect that "higher ups" within the Veritas support team have asked their subordinates to get closed as many of these outstanding issues.

This is the second question where a Veritas support person has responded with a nonsense or useless statement. Pathetic.

[Ryan_Russell]

Someone with a support agreement needs to call up and demonstrate this over WebEx. I tried to do that very thing this morning and couldn't recreate the problem again.

[Neil_Goldstein]

I am guessing that neither of you have a current support/maintenance contract?

If not, I will have to duplicate the problem on a standby server and then call in the bug.

So hopefully someone who is on 5520 and experiencing this can call it in.

-Neil

[Ryan_Russell]

I have a maintenance contract, I just can't reproduce the problem anymore. I'm doing the same thing this week that I did last week. This worries me more now that it's apparently not consistent.

[Deepali_Badave]

Hello,


we understand your concern.To analyze the exact cause of this issue we need to verify the certain logs and it will be easier to troubleshoot the issue online and to provide the solution.
So as suggested in our earlier reply please call us so that our technical representataive will assist you in getting resolve this issue.

NOTE : If we do not receive your reply within two business days, this post would be marked assumed answered and would be moved to answered questions pool.