Should I Install ABR10 build 11345?
I am using Build 10.0.11105. It seems to work fairly well, just some strange issues with AMS updating the status of policies.
I am usually of the mindset, don't fix it if it isn't broken. I am a little scared after hearing some people have problems with creating bootable media with build 11345.
The release notes hint at being able to import and export backup policies. That is one thing that has bugged me about my current build. I have to recreate a policy from scratch, I cannot disable it to do testing. Plus I am annoyed by the "deploying" or "revoking" status that seems to stay on forever via AMS (even though if I directly connect, it is pretty clear it is fine).
Does this build fix that issue? Is it worth the risk? Thanks guys!
I've tried to upgrade a management server by uninstalling the previous version and instalilng the new version.
Instead I keep getting a "a previous installation failed, rolling back".
On the other hand, I have been successful in upgrading every other piece to 11345. (agent, management console, pxe server, storage node). Although the storage node manager seems to error on reboot, but it seems to start anyway.
I am using SQL 2005 remotely, and even tried removing the old databases so it could do a fresh start.
Unfortunately, looking at the msiexec logs, it seems like it is trying to detect an 'upgrade', and since I have dropped the databases, it might never allow me to update.
Surely there is a workaround for this?
[edit]
I am able to get 11105's management server back on the system without a hitch. Very strange.
I realize it says this is not a good idea, but it seems 'somewhat' safe since all it should be doing is pushing policies.
[edit2]
Actually, it seems like I cannot use the management server at all if the versions are mismatched.
Looking at the installation logs more carefully, it seemed to hard error at the database installation, despite reading all of the sql queries fine.
I was able to resolve the issue by creating a NEW instance of SQL 2005 with the name of ACRONIS.
That said, I was incorrect on a few points and to clarify so others maybe benefits
First off here is the command I used to get the msiexec logs.
msiexec /i AcronisManagementServer.msi /l*v d:\log-name.log
Replace AcronisManagementServer.msi with the path to the install file (full path is safer). The d:\log-name.log is naturally the output log.
1) The installer does do some checks, but it actually does drop the databases and reinstalls them.
2) While it seems to throw a lot of errors, most are benign. Search for "failed" or look for the first "rollback" command.
3) Please note there is a distinction between a "database" and an SQL server instance. The case that failed for me was the "default instance" but for some odd reason I've also run into other issues with other vendors regarding that too. Looks like I have finally solved an ancient problem of mine and solved this new install.
4) The error message was misleading. The real problem was a failure to install the database pieces.
Remove everything as automated as you can, then there is a manual removal process that gets rid of the excess crap from a botched uninstall. Then reinstall everything.
I had to do this once. Search the KB for manual uninstall it's out there somewhere.
For what it's worth, 11345 seems fairly stable, there are some bugs though minor in my experience, but stable nonetheless.
Hope this helps.
Perhaps I put too much information in my previous post. I already solved the issue, and it had NOTHING to do with a previous installation.
As noted above in my previous post as point #4
4) The error message was misleading. The real problem was a failure to install the database pieces.
The "failed to install due to a previous installation" is misleading if not outright incorrect. This error will occur on a BRAND new install if your SQL server's instance is using the wrong collation (or perhaps acronis requires a named instance).
The install fails because it installs the SQL databases in the SQL instance (default or named) and somehow fails one final SQL related piece. So, it then rolls back thinking an old database was there, which is untrue.
I was able to resolve the issue by creating a NEW instance of SQL 2005 with the name of ACRONIS without any backwards compatible collations.
Perhaps a collation issue. It is rather annoying and frustrating that lately some vendors are doing something in their SQL that requires a certain collation and they are not mentioning it as a requirement.
What is even more annoying is not throwing the SQL errors back to the end user which would actually help us figure out the problem, instead of masking it as a "previous install" error.
Remove everything as automated as you can, then there is a manual removal process that gets rid of the excess crap from a botched uninstall. Then reinstall everything.
I had to do this once. Search the KB for manual uninstall it's out there somewhere.
For what it's worth, 11345 seems fairly stable, there are some bugs though minor in my experience, but stable nonetheless.
Hope this helps.
I concur that 11345 seems fairly stable and more worthy of production quality. Honestly the previous versions were like betas and should never have been released to the public.
One issue is the "partition error" issue which I just ran into this morning on one machine out of 6 or so.
They really need to start attaching the hotfix/kb notes right next to the initial download links. If it was not for the fact that I have been reading these forums a lot, I would have assumed something far worse was going on.
- Not every customer reads the forums
- Not every customer knows how to use the knowledge base
Post this as a "known issue" right next to the main download link.
That said the "partition error" is resolved with a hotfix to the SnapAPI.
Just so more people can spot it easily and google will spider more links to it.