Fab's AutoBackup 7 Pro - a must have tool for techs

[fabs]

@timeshifter
Feature 1 may not be that easy to implement as items are per user listed. Then, display order is hard coded so that may be a pain to make them dynamically sorted. I can try but I don't promise that will be in a final product.

Feature 2 needs a partial rewrite of the Outlook handling feature because like @fincoder said, if some files are not copied, related registry stuff (profiles and accounts) will not be processed. Removing OST support deserves some tests with exchange and IMAP accounts. In a general manner, I like to have the OST copied as it definitely speeds up email download process after a transfer. This is good from client's side but I understant it can be a waste of time on tech's side. Once again, deserves testing

 

[sapphirescales]

I understant it can be a waste of time on tech's side.

A waste of time? Come on. It only takes a few seconds to back up OST files unless you're backing up to an external hard drive like a caveman. Surely most of us are backing up to external SSD's by now and any modern system is going to have USB 3.0 ports. On the other hand it's not uncommon for it to take hours to redownload every email and recreate OST files from scratch.

 

[timeshifter]

I usually don't transfer OSTs not necessarily because I'm worried about file size and speed, but mainly because I think it's better to let them be recreated on the new system. It sounds like at least two of you @britechguy and @sapphirescales transfer the OSTs. That's your preference?
Not backing up to a hard drive, backing up to a fast SSD USB 3.x. But yesterday I couldn't help it that the machine was a 2nd get i5 with only USB 2.0 and a spinning hard drive.

Yes, I could yank the drive, but that's a pain. I'd rather (in most cases) let it run slowly than fool with that. Also, Fabs does better on a live system, I forget what it does better on the live system, but that's my preference when possible.

 

[britechguy]

@timeshifter,

Each of our preferences are just that, but couldn't you also just nuke the OSTs post restore?

This is one of those situations where some default was chosen, and I personally think it would be the one that most would actually want. If it's simple enough to add a selection as you wish, then I have nothing against that, but I'd still want the default to be to copy OSTs.

There are times, with any tool, where hand tweaking (or custom-written script tweaking) on the results is needed before kicking everything off when exception conditions or exception desires are involved.

 

[timeshifter]

What would be the point of backing up a large file, restoring it to a new system then deleting it from the new system? I just leave them behind as I mentioned.

I'm curious what everyone else does and why. Wondering what the pluses and minuses are for each approach.

 

[britechguy]

What would be the point of backing up a large file, restoring it to a new system then deleting it from the new system?

Well, it's not that there's a point to it, but if what happens (and it sounds like it's what's happening now) the only method available to you is what I suggested. I'm not saying it's ideal or desirable, but so long as Fabs does back up the OST file, and you can't control that, your only option is to nuke it once restored if you want to have it rebuilt from scratch. That's all I was getting at. And since I suspect the default to copy them will remain that way, until there comes a tweak you can make in Fabs to stop it, you've only got that way to achieve the stated end you seem to want.

Where there's a will, there's a way. That way is often kludgy.

 

[YeOldeStonecat]

What would be the point of backing up a large file, restoring it to a new system then deleting it from the new system? I just leave them behind as I mentioned.

I'm curious what everyone else does and why. Wondering what the pluses and minuses are for each approach.

I never...ever....ever...bring over an OST. I don't feel the need. Of course, I work with Microsoft Exchange...where "all" the data is kept in the users mailbox on the server, and the OST is purely a locally cached copy of there, there is zero data loss to the end user to not bring over the OST. It's not like it will have calendar entries or contacts that aren't on the mail server.

The OST is sometimes prone to corruption. If Outlook is having issues on an old computer, connected to Microsoft Exchange...a quick fix is to close Outlook and NUKE that OST file. Poof...gone. Open Outlook...let it rebuild the mailbox, done in a short time.

Calendar entries, Contacts, even signatures...are all stored in the mailbox on the server. (if 365, which is what I live in) Nothing needed to bring over.

When setting up new user profiles, I like things to be squeaky clean. fresh start. Moving over "stuff" from the old profile often brings over....garbage, the chance for bringing over hiccups. No reason to bring over an old, possibly wobbly OST. Zero reason! I auto configure Outlook usually...with InTune policies. But even manually, with autodiscover it's so easy a blind caveman can do it. Launch...autodiscover, password and MFA if needed, go to account settings, slide bar all the way to the right to download all email, poof, done! Let it cook for a few minutes, all done.
Unless you're on dial up with a computer with a 4800rpm spinner and just 4 gigs of RAM, or a really really weak gen1 DSL connection..with a HUGE mailbox....the OST rebuilds very quickly. And I say this knowing I have many users with well over 25, 30, 40, 50, even 75 or 90 gigs or larger mailboxes.

Granted I'm an Exchange/Microsoft 365 guy...with over 2,500 mailboxes under our watch across many different clients, but we are starting to (unfortunately) get a small handful of clients on Google Workspace. I'm a firm believer in Google email being used as Google intended, via browser. But for those who insist on using Outlook with Google ...(which..I thoroughly and completely detest)...yes there is some info there..."On this computer only"....so you are stuck having to retrieve those OSTs....and export as a PST....so you can import if needed...like if you're upgrading to 365.

 

[timeshifter]

In this case I was migrating a 365 BP user (two of them actually, two computers). In addition to the OSTs (more than one as they'd switched from AT&T hosting IMAP to 365 8 months ago) there were a bunch of PSTs that had accumulated over the years. I was just thinking it would be nice to pre-select only PSTs or a checkbox for PSTs and and checkbox for OSTs, it's a little tedious to scroll through the list and look for the file extension at the end to know which ones to select.

Any @YeOldeStonecat I'm with you on the Google hate - Google Workspace should be used in the browser. Just today with all this going on another tiny client with two users had their Google / Outlook break. I think it had to do with an update to the GWSFMO that caused a new Oauth request. On the newer PC the install got corrupted or something, took a while to unwind.

 

[YeOldeStonecat]

In this case I was migrating a 365 BP user (two of them actually, two computers). In addition to the OSTs (more than one as they'd switched from AT&T hosting IMAP to 365 8 months ago) there were a bunch of PSTs that had accumulated over the years. I was just thinking it would be nice to pre-select only PSTs or a checkbox for PSTs and and checkbox for OSTs, it's a little tedious to scroll through the list and look for the file extension at the end to know which ones to select.

Yeah, PSTs...if this is a "new client with unknown history"...and I'm doing a migration from <unknown crap email system> to 365...I'll open the PSTs in Outlook (or look to see if they're already connected)..and just peek at them. Lots of times from mis-fired "setup an account" thingies...you'll sometimes find a smattering of the little 256KB size PST which have..nothing...or..one or two deleted things.

 

[sapphirescales]

It sounds like at least two of you @britechguy and @sapphirescales transfer the OSTs. That's your preference?

Why not? It rarely creates a problem, and when it does it's a simple matter to simply close Outlook, delete the OST files, and open Outlook again. It's more likely that I get a frantic call from a client saying some of their emails are missing because it's taking forever to re-download all their emails.

 

[sapphirescales]

GWSFMO

The absolute bane of my existence. When I get a client with Google email, I set them up with a free Outlook.com account and use that for calendars. That's what I personally do as all of my email addresses (I have like 10 of them) are based on Google Workspace or whatever stupid name they're calling it these days. Alternatively I just leave a link on their desktop to Google Calendar which opens in their browser. Thankfully most of my clients don't use the Outlook calendar so I don't usually have to worry about it.

 

[fabs]

Hello,
Fab's AutoBackup 7 Pro and Fab's AutoBackup 7 Home & Office 7.19.0.7337 have just been released.
Here is the change log for both versions:
Added:
- Support for Enpass password manager settings
- Support for RustDesk settings
- Support for SyncBack settings

Removed:
- Pro only: when dealing with attached drives from another machine, the program now copies source Software, System and user registry hives to a temporary location and works with copies instead original files. This process was more or less already in place in previous releases but when copied files could not be loaded (it could happend with source encrypted drives using BitLocker for example), original hives were loaded straight from their original path. Now, copy method has changed and the program will ONLY work with copied hives and nothing else. Hopefully, we should get rid of that scary message saying that source operating system may become unbootable once job is done.
- Small bug when restoring data with "Move files from source folder" option enabled: even if files were moved properly, the program incremented failed files counter.


Grab it from your orders history's details on the shop's website.
You can also get update through the bundled updater tool: Click "Check for updates" on program's main window, then click the "Get Fab's AutoBackup7.X" link.

 

[fincoder]

7.19.0.7337 have just been released

Update from within the app didn't work (it said I was not paid up). Installed the new version by downloading from the order page OK.

First use with customer system drive, transfer operation was unable to load registry hive for Public. Older version worked OK.
Second use with different drive, transfer operation was unable to load registry hive for User & Public. Older version worked OK.

Note I had the warning about being unable to load hives during the pages for selections, before starting the transfer.

Drives were not encrypted. All data was copied including registry data using the older version. Both drives were removed from customer PC and connected to new PC for transfer. One was via USB, the other via SATA.

It doesn't seem like the handling of registry hives is working better (for transfer operations).

 

[fabs]

Update from within the app didn't work (it said I was not paid up). Installed the new version by downloading from the order page OK.

I guess your Fab's copy is still set with your previous license information. You need to put the new one using the key shaped icon then "Update license information" menu.

It doesn't seem like the handling of registry hives is working better (for transfer operations).

Since Fab's is accused of destroying source OSes boot ability, I have no other choice but trying to work around the problem. Because of this, the program only works with registry files copies instead of the originals. I guess registry hives copies got corrupted somehow and then could not be loaded. It looks like I need to find another way to copy them.

 

[fincoder]

I guess registry hives copies got corrupted somehow and then could not be loaded.

Yes, on 2 different unrelated customer drives. The only 2 I've tried transfers with the latest Fabs version. Should be easy to reproduce the issue with your testing?

 

[fabs]

Yes, on 2 different unrelated customer drives. The only 2 I've tried transfers with the latest Fabs version. Should be easy to reproduce the issue with your testing?

In fact, it's not that easy. It's a bit more like rolling dices and expect getting the same number each time. I would not have released this version if it was not working fine on my end. I thought it could be encryption related because I had one attached some day and I had the issue so I changed the way the program used to copy registry hives. It worked fine after that so I called it a day. Obviously I was wrong

Edit: I may finally have found something relevant explaining that issue and it has nothing to do with encryption or so.
Latest Fab's official version only copies a single file for each registry hive to the temporary folder. For example, for SOFTWARE registry file, it will grab it from Z:\Windows\System32\config folder and copy it to %Tmp%\ABReg. The problem is that there are other files that are required if the SOFTWARE reg hive is not in a consistant state (this can happen if computer was in sleep mode, if Windows was not shut down properly or maybe if it was shut down with fast boot enabled as it is a hibernation mode that does not say its name). So, if the additional files (.LOG1, .LOG2, .BLF, .REGTRANS-MS) files are missing from the temporary folder, Fab's will just not be able to load software registry file and you will get this issue. This is the same thing for other hives like SYSTEM and the NTUSER.DAT file that sits in user profile.

To address this, I have changed registry files copy code in order to include those additional files. If they are here, registry editor (Fab's uses it to mount the hives in command line) will then get the information it needs from them and will finally be able to load the hives.

So now, I have a theory about Fab's messing up drives : when Fab's used to load hives from their original folder, I guess registry editor used to write some stuff to these additional files (or empty them I don't know) so they did not match their previous state, leading to an unbootable operating system when drive was put back into original computer.

Just to make sure this is really the fix, can you please test this build against one (or both) source drives you are talking about ?
Here's a link for you: https://u.pcloud.link/publink/show?code=XZjvzx0ZLnDneKA0y6JdvMkfmV4CpkPn89wk

Let me know if it plays better.

By the way, I have also commented out disclaimer message about attached drives as I am confident this build will not break any source OS.

Thanks !