Error trying to upgrade to 12.1 RU1
Updated: 16 Feb 2012 | 9 comments
This issue has been solved. See solution.
I get this message on attempted upgrade to 12.1 RU1:
If I click Retry, the error comes up again. If I click Cancel, the install aborts.
The package was created from the SEPM.
Has anyone seen this before or know what it means?
Discussion Filed Under:
Comments
Try these steps
Hello,
Could you please let us know if this package is being shared on the Fileshare?
What happens if you Copy the package on your Local Hard Drive and run the .msi Installation??
Again, also check this Microsoft Article:
http://support.microsoft.com/kb/278425
Also, Try following the steps to install client packages to an existing manager
I believe after following these steps package should list under SEPM.
Export Package from SEPM and deploy on clients or use Auto upgrade.
http://www.symantec.com/docs/TECH96789
Hope that helps!!
Mithun Sanghavi
Symantec Technical Support Engineer, SEP
MIM | MCSA | SCTS | ITIL v3
Follow me on Twitter: @mithun_sanghavi
Don't forget to mark your thread as 'SOLVED' with the answer that best helped yo
Yes, it is being shared on
Yes, it is being shared on our DFSR.
The package works as expected if I create from the SEPM and run locally on the client.
The problem arises when I copy to our DFSR and let it replicate for a few days to ensure all our sites are covered. When I copy locally and run, this error comes up.
I do not run the MSI but I run setup.exe.
Endpoint Knowledge Base
Security Best Practices
can you create another
can you create another package and try installing?
Cheers!
Pete
Help Link: http://www.symantec.com/business/support/overview.jsp?pid=54619
If I create the package in
If I create the package in SEPM and run locally on the client needing to be upgraded, it works fine.
It only seems to be when I copy from our DFSR and run locally this problem arises.
Not exactly sure why copying from the DFSR seems to cause an issue.
Endpoint Knowledge Base
Security Best Practices
sorry for asking this again,
sorry for asking this again, does it happen with newly created package as well?
if you push through SEPM, is the error still exist?
Cheers!
Pete
Help Link: http://www.symantec.com/business/support/overview.jsp?pid=54619
A package created from the
A package created from the SEPM does not have this issue, only when put on our DFSR and than copied from the DFSR to the client the problem comes up.
I don't push thru the SEPM. We use SCCM for deploying. However, I keep the packages on our DFSR as well in case we need to remove a client and our techs can do a re-install using the package on the DFSR.
Endpoint Knowledge Base
Security Best Practices
Hi, Could you check on client
Hi,
Could you check on client workstation, whether BASH driver startup type is set to System ?
Computer Management --> Device Manager --> Non plug and play drivers --> BHDrvx86 --> Properties --> Drivers
If you are not able to see Non plug and play drives, enable show hidden devices
Thanks and Regards,
Chetan Savade
Technical Support Analyst,
End Point Security, Enterprise Technical Support
I'm upgrading from 11.x so I
I'm upgrading from 11.x so I don't think this applies?
Endpoint Knowledge Base
Security Best Practices
The reason you are having the
The reason you are having the problem with DFS is that not all the files are copied. By default, *.bak files are not replicated in DFS, and the installer is looking for one. In our case, it was the BASHOpst.bak file that was missing. You need to edit your DFS configuration to allow .BAK files to replicate (taking into consideration any repercussions this may have in your environment). Once the configuration change has replicated, then DFS should automatically replicate the skipped file.
Use a file comparison tool, like WinMerge, to do a quick comparison of the original directory versus the replicated directory. You may need to make other adjustments to your DFS replication filter.
Would you like to reply?
Login or Register to post your comment.