Hi! I did a migration from one ispconfig-server to another, using the migration toolkit (https://www.ispconfig.org/add-ons/ispconfig-migration-tool/) and this guide https://www.howtoforge.com/tutorial...-confixx-plesk-to-ispconfig-31-single-server/ After a succsesful dry run, here I got this error (and some following errors depending, which seems that they are depending on "does not exist as primary"). Code: 2022-06-16 17:24:52 - [ERROR] API call to mail_user_add failed. 2022-06-16 17:24:52 - [ERROR] JSON API REPLY ERROR: Mail domain - weinbau-HIDE.at - does not exist as primary. - Arguments sent were: array ( 'client_id' => '35', 'params' => array ( 'server_id' => '1', 'email' => '[email protected]', 'login' => '[email protected]', 'password' => '$6$rounds=5000$HIDE$mcm76iqrxbEf68hiQHIDEYojmj10Puf.3PHIDEBi5xF/', 'name' => 'Weinbau HIDE', 'quota' => '18874368000', 'cc' => '', 'maildir' => '/var/vmail/weinbau-HIDE.at/info', 'homedir' => '/var/vmail', 'uid' => '5000', 'gid' => '5000', 'postfix' => 'y', 'disableimap' => 'n', 'disablepop3' => 'y', 'autoresponder_subject' => 'Out of office reply', 'autoresponder_text' => NULL, 'autoresponder' => 'n', 'autoresponder_start_date' => '2012-01-01 00:00:00', 'autoresponder_end_date' => '2012-01-01 01:00:00', 'move_junk' => 'y', 'custom_mailfilter' => NULL, 'purge_trash_days' => '0', 'purge_junk_days' => '0', '_ispconfig_pw_crypted' => 1, '_ispconfig_unix_datetime' => 1, 'sys_perm_user' => 'riud', 'sys_perm_group' => 'riud', 'sys_perm_other' => '', 'maildir_format' => 'maildir', 'forward_in_lda' => 'n', 'sender_cc' => '', 'greylisting' => 'n', 'access' => 'y', 'disabledeliver' => 'n', 'disablesmtp' => 'n', 'disablesieve' => 'n', 'disablesieve-filter' => 'n', 'disablelda' => 'n', 'disablelmtp' => 'n', 'disabledoveadm' => 'n', 'disablequota-status' => 'n', 'disableindexer-worker' => 'n', 'last_quota_notification' => NULL, 'backup_interval' => 'none', 'backup_copies' => '1', '_ID_' => '48', '_migrate_status' => NULL, '_migrate_status_type' => NULL, '_migrate_status_dep' => NULL, '_primary_id' => '48', ), 'session_id' => 'fff669733a7d99ad0943bb736cfc63127734f60e2', ) How can I make sure that I have not imported an error onto the new server that will cause problems in the future? Thanks for the information!
According to the error message, there is no mail domain for the email address of this mailbox. Check the migrate.log if the email domain of this mailbox was imported and if you don't find it, check your old system to ensure that there is a mail domain for this mailbox, as each email address needs a corresponding mail domain.
There is a Maildomain for this domain on the old System - its active and the Mailboxes are receiving Mails. I doublechecked this, the maildomain is up and working on the old System.
Check the migrate.log if the mail domain was migrated, if it's not listed in the log, or if there was an error in adding it. And in regard to your first question, the mailboxes could not be added at all, so you did not create an error on the new system. but they are missing at the moment because the import failed due to the missing mail domain.
After finishing the migrate-script (syncing the files of webspaces and mail) the script exited with Code: ERROR 1049 (42000): Unknown database 'c35datab01't ERROR 1049 (42000): Unknown database 'c35datab01't ERROR 1049 (42000): Unknown database 'c35datab01' [ERROR] job failed. Stopping Sync! Thats related to the same customer c35 as before (maildomain). On the new system the customer is c35 is created by migrate-scripte, but no webspace and no maildomain. Furthermore the migrationscript sends this output: Code: Starting API calls. [38/38] <Client> processing HIDE_2bernhard (C38) [ERROR] API call to domains_domain_add failed. See log file for details. [51/51] <Domain> processing HIDE_2grafik.at [ERROR] API call to sites_web_domain_add failed. See log file for details. [WARN] Could not find parent record for domain weinbau-HIDE_1.at. [50/50] <Website> processing HIDE_2grafik.at with autosub www [10/10] <Website> processing businessftp.meindHIDE_3.net with autosub none [ERROR] API call to mail_domain_add failed. See log file for details. [31/31] <MailDomain> processing HIDE_2grafik.at [ERROR] API call to mail_user_add failed. See log file for details.-HIDE_1.at) [46/46] <MailUser> processing namaste@meindHIDE_4yoga.at (namaste@meindHIDE_4yoga.at) [26/26] <MailAlias> processing alias [email protected] -> [email protected] [2/2] <Mailfilter> processing printHIDE.at [ERROR] API call to mail_spamfilter_user_add failed. See log file for details. [69/69] <Spamfilter> processing namaste@meindHIDE_4yoga.at [1/1] <BlackWhiteList> processing whitelist *@brzxyz.gv.at [5/5] <SubAliasDomain> processing aliasdomain HIDE-world.eu [WARN] storeFTP: Could not resolve 64 to new web domain id. [27/27] <FTP> processing HIDE_2bernhardftpHIDE_2 [ERROR] API call to sites_database_user_add failed. See log file for details. [24/24] <DBUser> processing c38dbclientHIDE_2 [ERROR] API call to sites_database_add failed. See log file for details. [ERROR] API call to sites_database_add failed. See log file for details. My big concern now is that I will have the same or even more problems on the new server than on the old server. Only one line in migrate.log is about "domains_domain_add". And this line is related to c35. I have two main questions: Is it possible to run an integrity check on the new server? Is there such a thing with ispconfig? Is it possible to setup a new webspace and maildomain on the new server and do the sync again? Thanks for working on this!
No, there is no such script. Theoretically yes, practically it is quite unlikely that you are able to manually create the needed records with the right id's so that it would match in the end. Without having the full migrate.log file, I can't say much about these issues. You should use our support contact options at ispconfig.org as I can't help you here in the forum without the full and uncensored migrate.log file. And it might be useful to know what the exact issue son the old system are and how the old system database got broken in that way, e.g. was data in the database manipulated manually or was inconsistent data added by using SQL or the api etc. As all these issues affect just one client, you might even consider migrating the other clients only and exclude this client.
Thanks for all your time spending on this issue, but I prefer to migrate by hand. It feels safer and I need a good base. Moving by hand is certainly faster and safer, even if it is a lot more work. I have two more questions regarding the move, I will ask these in separate threads.
