From: Eddy Chan at Business Catalyst | Please read in preparation...

In the 24 hours since I published my last OpenSRS Mail Migration update yesterday a slew of questions have sprung up both in the comments thread and also in a thread on our own support forums called 'OpenSRS Transition'. These are all valid questions, I understand your concerns and I'm posting again today to do my best to openly and honestly answer as many of them as possible in one place:

Mail Migration Q&A

Question: When the transition occurs (prior to password resets) will email continue to collect or does the password routine actually activate the email box creation?
Answer:Yes mail will collect inside the OpenSRS mailbox before the password reset. Any mail that was collected in the old MailEnable account prior to the cutover will be gradually migrated across to the OpenSRS mailbox as well

Question: If email box creation is not dependent on the password being created will aliases also receive / deliver email (including common domains). these are set in users in the dashboard? Will existing email forwards still be active or need to be manually created?
Answer: Yes, any Aliases and Forwards setup in the current system will be carried automatically over to the new mail system and mail will continue to be delivered via those

Question: If an email account is a catch all currently will it act as a catch all after the transition or will it need to be re initiated?
Answer: Catch-alls will no longer be available with OpenSRS - they are not supported because they contribute to spam since they do not trigger bouncebacks for non-existent email addresses. Customers will need to setup aliases to catch email sent to common email addresses such as sales@, help@ et.

Question: Will webmail address books transition across or need to be saved and reimported (can they currently be saved)?
Answer: Unfortunately Webmail address books can't be exported, this functionality simply doesn't exist in MailEnable so we will not be able to migrate these across.

Question: Do all users need to have their passwords reset? Do Admin users who do not user BC mail servers also need to reset their passwords?
Answer: Yes all users have to have their passwords reset including Admin users who do not use BC mail servers because we are making an upgrade to our security infrastructure. I would've avoided this if I could just so that those who had BC hosted email needed to update their passwords but there was no workaround.

Question: As "email only" users (i.e BC mail users) can not log in anywhere to change their passwords I presume that any such change will need to be performed by an admin user for that site or the partner needs to reset the user password and then convey the new password to the users. Is this correct?
Answer: No, email only users we need to go to this URL https://secure.worldsecuresystems.com/ChangePassword.aspx where they will be given a 'Change Password' portal that looks like the following screenshot.

Question: What is the timing for this change of password or "triggering" to occur?
Answer: Our current plan is to have it occur on Friday morning (US Pacific), this will be Saturday early AM in Asia-Pacific and Friday evening in Europe. Once I have the exact schedule I will be updating all partners with it.

Question: Is there any way in which partners can obtain a list of all users for each client site as a single report. I only have 28 sites but I hate to think of what this all involves for those with a lot of BC sites
Answer: Unfortunately not at this moment - we are relying on Partners to make contact site owners and provide them with the instructions that I have drafted here. Site owners can then pass the message onto their site users. Obviously, this process isn't optimal and this communication chain is something I'm looking to improve in the future.

Question: For users who have a mail client like Outlook and don't login to a user interface, how will they know when it is time, and how to go about updating their passwords?
Answer: As their BC Partner, you will need to send them an email. I've thought long and hard about this one, we had to take white-labeling considerations into account and if we were to send a very generic "Please Update Your Password" email with an unrecognized link it would've looked like a phishing scam. We would rather partners send out a email with their own branding from a trusted email address warning their clients that their online business hosting vendor is about to undergo a security and email upgrade. I will be publishing this email for you to send to your clients as soon as we have exact details

Question: Will there be extended coverage of support and 3rd party vendors support this coming weekend as a backup during the transition aftermath?
Answer: Given that we are on schedule to run the migration on Friday morning (US Pacific) we will have support and engineering teams to provide coverage for email related issues this weekend. OpenSRS will be providing our team with vendor support as well throughout the weekend. I met personally with a couple of their folks in San Francisco this morning and we have their assurance that we're in good hands from a vendor standpoint.

Question: Should I be notifying my clients of possible email black outs where they will lose emails relating to the new logins?
Answer: Your customers will not lose any emails throughout the migration. What will happen though is that once the DNS switch is made, it will take some time for the mail that arrived in their MailEnable account to appear in their OpenSRS account. I've allowed for up to 72 hours in my communications but the engineering team is quietly confident that we can keep it down to 36 hours at maximum and less in most cases.

Question: I'm hoping that BC will put out a "Tech Notice Email Newsletter" to all partners with step by step instructions of what's required for a smooth transition on new SRS, prior to the migration. (Not all the partners read the blog or dig out the info from forums). We will need a final definitive set of instructions to share with our customers to make it easy for them. An official email from BC outlining whats required would be great.
Answer: I will be sending out a final set of instructions to ALL BC Partners tomorrow via email. The reason I have held off sending it thus far is that I don't want you jumping the gun and updating passwords before we've even made the necessary system updates. I've also been waiting on the engineering work for the migration to be verified so we can be exact with dates and times as well.

Question: Just adding to this post - I agree with the comments in this thread - aside from the BC Blog post regarding the migration, can you provide specific step by step instructions that we can give to our clients, as there seems to be a lot of confusion here with exactly what needs to be done.
Answer: As answered once I finalize the client communications email, you will be able to download it, customize it and then send to your clients.

Question: What happens to email accounts that we manually migrated, on your advice, earlier in the crisis? Will they also experience the "reset your password" step?
Answer: Their OpenSRS accounts will not be affected by the mail migration, however they will still need to reset their Admin Console passwords or use the 'Change Password' portal for mail-only users as we are upgrading our security infrastructure in BC

Question: Will the users be required to clear their mailbox completely BEFORE the transition and if not will they lose whatever they have not retrieved (ie unopened emails)?
Answer:Yes, if your clients have IMAP or POP setup, they should be trying to download their latest emails. Whatever they do not retrieve will be migrated to the new accounts within 72 hours after the switch has been made.

Question: Why are customer accounts treated with less security than user accounts? Business Catalyst currently stores raw passwords for customer accounts, hence why I can view a customer record and see their password. I presume this is different for user accounts but why the difference? Anyone can create a BC site and collect passwords. I don't agree with it but that's how your current system works. I'm just wondering why a customer account (password) is deemed less important. Would love a reply to this one
Answer: Customer accounts on sites are not deemed any less important, they just run on different security infrastructure. This is something I will fix in the BC V3. I agree the CRM passwords should be made much more secure so people can't create BC sites to collect passwords.

Question: An end consumer here - what are you doing about CMS that are accessed using email address? Not being able to update web / post blog comment is going to be crippling.
Answer: Users will still be able to access the CMS using their existing password. They will have a full month to reset/change their password. The pressing issue here is giving them access to their new email accounts which means they need to reset or change their password immediately.

I hope this provides a lot of the answers that Partners have been looking for. My apologies for any confusion caused yesterday, it's my job to make everything as clear and concise as possible. Your feedback so far has been appreciated. I will continue to update this blog on a daily basis with news about Mail Migration until it is completed and all issues are resolved. Thanks for reading!