GSUITE: Migrating email from old domain after having moved domain name - email

The current mailprovider has had technical issues for more than 14 days now until last night when their servers came offline.
They are insisting that the issue will be solved, but I've gone ahead and prepared to move to gsuite.
I started the mail migration tool several days ago but it fails after migrating a few mails due to the old providers tech issues.
My question is:
If I move the MX records to gsuite, I will receive emails again, but would it then be possible to migrate old mails at a later time? (In case the my old provider fixes their issues?)
My concern is, that when I move the domain name, I will no longer have access to my old emails on the old server.

I've moved the MX records so, that new mails will appear in gsuite.
This means, that the old mails won't migrate, since the MX records has changed.
When the old host, hopehully works again, I'll switch the records temporarily, move the mails and change the MX back to gsuite again.

Related

Outlook Application wont send mails every second instance

I know I should probably ask MS about this, but I dont know if I trust their communication tools to get me a satisfying answer.
I have recently taken the task to test an application of mine.
Part of this test is to send an e-mail to it, then log in and see if I get the result I want (this is automated)
For this the process is:
Open Outlook -> Send Mail
Close Outlook
Open App -> Check result
Open Outlook -> Send Mail
Close Outlook
But for some reason, every second time the outlook app is opened, (including manually opening the app to check on configurations etc.) Mails will go to the outbox but will not be sent, unless I manually trigger them to.
Now, there are possible solutions like keeping the app running continously, or telling my testing-suite to press F9 after every sent mail, but I want to tackle the root cause, and fix the underlying problem.
The Outlook Version used is the latest Version of Office 365 Outlook.
Has anyone else had this experience and figured out a fix?
Thank you in advance.
Keep in mind that message submission is an asynchronous process, so if you close Outlook while it is still sending, the message might end up stuck in the Outbox.
You can call Namespace.SendAndReceive to force submission, but it is still asynchronous. You can hook into the SyncObject.SyncEnd event on the first (All Accounts) SyncObject from the Namespace.SyncObjects collection and quite only after that event fires.
Since this problem occured on a machine I do not own, I tried avoiding certain easy troubleshooting steps. After I couldnt find an answer on my own, and I didnt get responses here that would've helped me solve this without a wooden hammer method, I asked for permission to issue a repair to the local office 365 suite.
After the repair it had redownloaded and installed the entirety of office 365.
After connecting my company MS account to outlook, the issue no longer appeared.
I guess this counts as solving this issue.

G Suite Email Migration Does Not Complete, Stuck on 99%

I'm currently experiencing something rather weird: while migrating emails from a GoDaddy email server to a new G Suite set up for a number of users, I was able to successfully move for a couple of emails, as confirmed by Google's 'Complete' tick beside them. I was able to observe the migration too as it went on.
However, for one of the emails, the number of emails read just seems to keep increasing, and it still hasn't displayed 'Complete', but remains stuck on '99%'.
See screenshots I literally took just now below: as of the first latest screenshot, it says 'Successfully migrated 3230 emails', while stuck on 99%:
Then I hit refresh, check the status of that same account, and now it says '...3250 emails', while still stuck on 99%:
This isn't how it's supposed to behave, at least that isn't the behaviour I experienced with the previous 4 emails in that list. Ideally, it should say 'Migrating X out of fixed_amount emails'. In this case, that fixed_amount was
about 2,000 emails. It has now since passed that figure, but instead of showing 'Complete', it instead shows 'Successfully migrated new_amount' where new_amount keeps increasing.
This has been ongoing for almost 24 hours now. Honestly, I don't know if this is a bug or not. I really just need some helpful info to know if I should be concerned or not, perhaps maybe if someone else has run into this. Anyone?
Stumbled on to Google's documentation: https://support.google.com/a/answer/7032598?hl=en
To quote the 'Why does my migration look like it's stuck at 99%?' section:
You’ll see 99% when all email is migrated. After everything is
migrated, the data migration service applies any labels to the
migrated email, which can take time. When the labels are applied, you
should see that the migration is complete (100%).
You might also see this issue if the estimated number of emails to
migrate exceeds the actual number of messages. The migration will
report 99% until the migration completes. This process might take some
time.
You shouldn't be concerned. I was migrating around 29.000 emails from a personal gmail to Google Workspace gmail and the migration took 4 days (migrating only one user), from which the last 1.5 days the migration was "stuck" at 99%. No need to restart the migration, eventually it indeed finishes. I also got several error codes (e.g. 17009 - 'Generating an access token with the supplied credentials was unsuccessful...'), but none proved valid, I haven't actioned on them as, like in your case, I saw the number of migrated emails increasing.

Is there a way to delete MX records from a Cloudflare App?

I'm working on an app that updates the site's MX records to redirect mail for the site to our servers. I'd like to be able to remove the MX records we add when the site is uninstalled, since at that point we'll stop accepting mail for the domain. It seems like other record types, such as TXT, are removed on uninstall, but MX records are not. Is there a way I can remove them?
MX records should be removed with an uninstall as well. Did the zone you test on have the mx record prior to installing the app? Have you tested with multiple zones? I recommend creating a test zone (doesn't have to be active) and not adding any mx records then see what happens.
This was a bug, which has since been fixed. MX records are now correctly removed when the app is uninstalled.

migrate postfix accounts into google apps

I have a postfix server (Linux) hosting a large amount of emails (120GB for 70 accounts) to be migrated into Google Apps. Only 30 accounts remain active and the remainder are archives.
What is an efficient way to migrate active accounts into Google Apps and minimize disruption? Are there scripts to read direct from the server disk then upload? What about folders and email statuses (read/flagged)?
Depending on the needs of your users, it's usually easier to cut over the MX records first and send your users to Apps for all new mail. Then, migrate over their old data. In this case, the downtime is very limited and they can always access the old server should they need something there.
The alternative would be to do multiple waves of migration that look something like:
Migrate all data from data X - Y
Change MX records for all users and send them to Apps
Run a second migration from date Y - Z to pick up any of the missed data (there won't be duplicates in emails if there's some overlap)
Regarding your last point, I'm guessing your users are using at least IMAP to access the mail server as I believe Postfix is not a mail server on its own. If this is the case, you'll want to use an IMAP migration for which Google provides a tool for (GAMME). An IMAP migration will bring over folder structure as well as read/unread status but I don't believe any 'flagged' status will translate.

After Zarafa update all emails were lost

After my Zarafa (Small Business) update to version 7.1.7 all emails were lost. The accounts are still there.
What can I do to solve the problem quickly?
From which version did you upgrade? What do the Zarafa logs say, specifically /var/log/zarafa/server.log (or if you configured syslog instead, what does that log say)?