New build 5.3.1.59332 - issues and bugs discussion

Do to the catastrophic loss of my remote replication core, I decided to start from scratch and install the latest build (5.3.1.59332) on new hardware.

I wanted to create a thread where we can consolidate all of the bugs and other issues for this new version in one place.

So far I have discovered the following issues:
1) UI response time is now very slow with some operations. It's similar to how the old 5.2 used to be and possibly even slower. This can be very frustrating since it takes 30 to 60 seconds or more per click in the UI.

2) The option to pause / un-pause replication jobs is now gone in this version. The option is no longer in the menu. This is a problem and leaves you no control over replicating machines.

3) The well-known attachability checking and log truncation bug still exists in this version. Nightly attachability checks and log truncation still constantly fail as before in older builds.

Please post any other issues or bugs you find and possible solutions if you have them.

  • There is a way to install a new core and then move your existing repository and configuration to it. I was actually going to give it a try before I completely lost my replication core.

    Search for "Steps to recover/move a repository on AA5" in these forums or in Dell's knowledge base.

    Here are the basic steps:
    1) Move the existing repository to wherever you would like for it to permanently reside, this CANNOT be changed later. As an example we will call this path D:\Repo
    2) Create a new "dummy" repository on the core, you can use any size, I would recommend something like 1GB. Create it within a nested folder of the old repository you are trying to recover - in this example it would be D:\Repo\Dummy - remember, if you used different paths for the data and metadata before, you need to do this again (You could use something like D:\Repo\Dummy\Data and D:\Repo\Dummy\Metadata)
    3) Once the repository is created, stop the AppAssure Core service.
    4) With the core service stopped, move all of the old repo (repo you are trying to bring in) data files, into the nested directories, overwriting them, remember keep the data and metadata in their respective directories, if you used the same directory for both, no need to worry. (Using the example paths again, you would move the data files from D:\Repo\Data into D:\Repo\Dummy\Data, and the same for the Metadata, if you used the same directory for both, you would simply move D:\Repo into D:\Repo\Dummy) It is important to move (drag and drop) the files rather than using copy/paste, if you do this you will end up with two copies of the files consuming twice as much space on your disk.
    5) Once this is complete, restart the core services, the repository will now go into maintenance mode and be scanned. This process can take several hours.
    6) Finally after the scan is complete you will see your agents listed as abandoned or recovery points only on the machine tab, to reconnect with the agents you will need to go to each one and perform the repair orphan action. Keep in mind, any old snapshot settings, such as interval, retention, etc will be lost, you will need to set these again.

  • To pause/unpause replication, on your core, create a bat file. Place the following in it to pause it and change the "yourreplicatedcore" to the exact FQDN or name you chose as your replicated core:
    @echo on
    "C:\Program Files\AppRecovery\Core\CoreService\aacmd.exe" /pause Replication -outgoing yourreplicatedcore

    Then create another bat file to resume it:
    @echo on
    "C:\Program Files\AppRecovery\Core\CoreService\aacmd.exe" /resume Replication -outgoing yourreplicatedcore

  • my replication actually has been working for two days on the new build. That's a record for me in the last few months/builds.

    Jason

  • My replication is still broken. My replicated server is still full and will not clear out the old replicated points.

    I am afraid I am going to have to blast that core away and start over. It takes weeks to replicate the data over...

  • Something else to add:

    After the Daylight Saving Time change this weekend, all my backup job start times are off by one hour. This happened last fall too and they were supposed to fix it, but I guess they didn't. That's just a rookie mistake that I might expect from a college programming student, but not enterprise software developers.

  • In reply to je147:

    That's exactly how pausing replication has been done in previous versions, but the option was gone after I installed this latest version.

    I think I just figured out the solution though. Clear your browser cache.
    I did this and now the option to pause / resume has returned.

  • Replying to @jproos's post:

    What browser are you using? Support has said to use Chrome, and it works pretty well for me.

  • We are getting the following error when an ExportJob runs:

    Tevo Library Error Exception

    TevoGetFlagsInOfflineVolume failed with error -2147024893 (0x80070003 - The system cannot find the path specified)

    Also the Exchange mountability checks fail with this error:

    AppRecovery.ExchangeCheckHost (1092) DSM_JET_INSTANCE: An attempt to determine the minimum I/O block size for the volume "C:\ProgramData\AppRecovery\MountPoints\b16f8db3-ae8b-4710-816b-31a3786473ea\L__\" containing "C:\ProgramData\AppRecovery\MountPoints\b16f8db3-ae8b-4710-816b-31a3786473ea\L__\Mailbox\Mailbox Database 1730760347\" failed with system error 64 (0x00000040): "The specified network name is no longer available. ". The operation will fail with error -1022 (0xfffffc02).

    Anybody else have these issues? These alls tarted with the upgrade to Server 2012 per AppAssure recommendations. Been waiting 2 weeks for tech to solve these issues.

  • you do know that Appassure don't support Exchange mountability checks if the core is running Server 2012.

    in fact I don't think they even support restore of mail items, just the whole volume (to restore single items you need to use Local Mount Utility on server 2008 R2 and mailretriever on there.

  • Replying to @voffice's post:

    I don't think that's true. My 2012 core has been doing mountability and checksum checks on two Exchange servers, it just doesn't do the mountability checks or log truncation reliably during the nightly jobs. But, I can manually run the check and truncation and it works fine every time.

    Haven't tried the Local Mount Utility on the server though. I usually run that from a workstation anyway.