SYM06-024 December 13, 2006 Symantec Veritas NetBackup: Vulnerabilities in NetBackup Server and Clients. Revision History None Severity High (very configuration. The cat version shows NetBackup-RedHat2.6.18 7.5. You will have to re-install the 7.5.0.7 Client patch with a 'force-install' option (-p). Run ' /bin/sh NB_update.install -p ' So, to summarize: 1. Update Client type in policy 2. Re-install 7.5.0.7 Client patch (with -p option) 3. Verify patch version in /usr/openv/netbackup/client/Linux/.

Yes, I have Solaris Master/Media Servers and am having issues, mostly centered around two areas 1) Inline tape copies w/ Oracle agents The nbemm and nbrb processes seem to get stuck in loop as soon as the policy is run. They both suddenly use quite a bit of CPU, as seen by 'prstat'. Subsequent requests from currently running jobs or jobs that run after the 'bad' policy for resources such as tape drives or tapes are not granted.

Eventually all jobs grind to a halt awaiting resources. 2) Vaulting from Basic Disk storage units During the Duplication phase for vault, seems as though after 9 images are copied, I get an error 50, client process aborted. I can restart the vault session and the next 9 images are copied. Duplicating from tapes seems to be unaffected. Iboostup Premium 3 5 Cracker. What I see is that when installing the patch the installer reports 'terminate all backup prosesses antd try again' even if al prosesses is terminated. I have this problem on more than one W2k server.

Message Edited by Kenneth Hansen on 03:57 AM O In answer to the original question. I had this issue. And solved it.

It seems that when you do the install on windows the wininstall puts its 'working' files on the drive that has the most room. NOT always C: on my server S: had the most room (320 gig free). Problem was that S: was a shared out drive. They wanted me to take the share off ( could not it was it a prod server). So to work around it (my cd's were copied to disk).

I went to the install files into the PC_Clnt/x86 and did an edit on 'slientclient.cmd' modify the the last line, and add to the end ROOTDRIVE = C: removed any files in C: temp that were leftover from the first try. I saved the file and ran the install again. This forced the install to build its temp files on the C drive, and it worked just fine. When done, I took that part out of the file so it was back the way it was. Just an FYI in case anybody looks at this for the original error. Well I'm still on 6.5.2A /Solaris 10 master with an engineering nbpem.

Ive sent gbs of logs to symantec, Ive spent hours on webex sessions and still Im finding that scheduled jobs are simply skipped and support, whilst its involved plenty of dedicated man-hours, hasnt delivered. Regression testing?I have my doubts. Last night I had zero jobs run: thats a first! I suspect this is actually different to my initial problem which was the odd scheduled job fails to run. Anyone getting closer to a solution?