I finally had enough office time to commit to the installation.

The only hiccup I experienced was that the documentation didn't suggest to copy custom Sogo config files to /opt/iredmail/custom/sogo.

As a result, my Sogo Prefork and Workers settings were defaulted to the install values, which are incredibly low.

Since Sogo stores the prefork setting in /etc/default/sogo, where do I put that value to ensure upgrades don't overwrite it?

Mentioned SOGo related changes in migration tutorial:
https://docs.iredmail.org/iredmail.to.e … -groupware

Thanks for the feedback.

As a reseller offering email services, I used to customize the Pro admin UI templates a bit — mostly to hide advanced features from my customers, or to change the logo to reflect my brand, so clients would identify the interface as part of my service.

Hi Juanito,

- Recent EE release supports custom branding.
- What kind of features do you need to hide from customers? There're few features available to hide, same as iRedAdmin-Pro. I wonder any other features you want to hide.

The only hiccup I experienced was that the documentation didn't suggest to copy custom Sogo config files to /opt/iredmail/custom/sogo.

As a result, my Sogo Prefork and Workers settings were defaulted to the install values, which are incredibly low.

Since Sogo stores the prefork setting in /etc/default/sogo, where do I put that value to ensure upgrades don't overwrite it?

As a reseller offering email services, I used to customize the Pro admin UI templates a bit — mostly to hide advanced features from my customers, or to change the logo to reflect my brand, so clients would identify the interface as part of my service.

Now, with the new binary-based EE version, it seems there’s no way to configure or hide these elements anymore. Is there any workaround planned, or should I consider this a permanent limitation?

Thanks!

It also generates config files for all involved software, so it's very important to split the customizations you made in software config files to /opt/iredmail/custom/ manually. iRedMail EE maintains the core config files, and you override them with custom settings defined in files under /opt/iredmail/custom/, so it should work well and not lose anything.

Hello group,

Thank you to Zhang and the team for providing an upgrade path from iRedAdmin-Pro to the Enterprise Edition.

I've followed the instructions at this link: https://docs.iredmail.org/iredmail.to.ee.html

...and then went to the Install iRedMail Enterprise Edition document which is under a heading that says "Run the full deployment as migration".

Executing /usr/local/bin/iredmail results in this message on the CLI: "Seems server doesn't have iRedMail Enterprise Edition installed, launch installer on port 8080." which is true - I've never installed EE on this machine, but it does have iRedMail and iRedAdmin-Pro installed on it.

After a brief battle with firewall rules to open port 8080 on the server, I started through the installation wizard.

I stopped just before the final "Confirm and Deploy" button because it didn't seem like the installation wizard knew that this was a migration. I expected that some choices would be pre-filled based on what I've already got running on the server and their existing configuration.

How is the deployment of the Enterprise Edition deployment wizard supposed to be run as migration? Or is there no difference and I just need to answer questions like "First email domain name" and "LDAP Suffix" in the same way as the server is configured for it to treat the install deployment as a migration deployment?

I'm hesitant to press the "Confirm and Deploy" button on this production server because of the verbiage describing running the install as a migration, but then seeing no indication the wizard thinks it is a migration - can anyone describe their experience here to give me some confidence?

Thanks!