Migrating Clients from old to new Zentyal ??

[vshaulsk]

I currently have a zentyal 2.2 system running.  However once zentyal 3.2 comes out I was thinking of making the migration.  I don't mind having to recreate all the firewall rules and special custom features I have done to my 2.2 installation.  However I have some questions on how I would migrate zarafa, clients and their work stations.

My zentyal 2.2 machine has the users and groups module running.  I have 10 windows 7 machines that authenticate their local profiles against the zentyal server (domain is zentyal.lan).  The total client count is actually around 15 people, but I do not use roaming profiles. 

Also each client has a zarafa email account.  Zarafa MySQL database gets backed up every night using a script.

When I switch to Zentyal 3.2 I know that I will have to create a new domain and probably recreate all the users.  Does anyone know how I would migrate each users local profile on each windows 7 machine to the new domain.  I don't want the users to loose any data they might have saved on their desktop.

My second question is how would I get the clients emails back.  I don't think that a zarafa MySQL restore will work since this will be a completely different system.

Since I have very few users I don't mind having to migrate each user manually, but I just need some direction.


For any other data stored on zentyal I will use my backups to restore it (shared folder data and any files clients saved on their network folder).

[christian]

That's rather a question for Zentyal team isn't it? Will they provide migration tool ?
Given the fact that you have quite few users and depending on your mail client, can't you perform local backup (client side) that you will resynchronize once new account is created ?
This works with IMAP. Then Zarafa is supposed to bring other features for which I don't know the very detail therefore can't guaranty it will work. However this is the direction I would look at first if there is no migration path provided by Zentyal.

[half_life]

I can speak to the email problem.  I have already moved from 2.2 to 3.0 on my home installation.  There are directions on the zarafa website how to migrate from one version to another using imapcopy (or similar) to transfer accounts.  In essence you temporarily suspend password checking on the old and new system and copy the users mailfolder in a hand over hand fashion.  I will be pursuing the same thing on the work install but have yet to get the scripts together to automate that process (time is short when you run a department of three.  Me, myself, and I.)

[christian]

Do you mean that everything is stored is user's mail folder, meaning available via IMAP protocol ?
I don't know why but I made the assumption that "groupware" related information was stored differently. On the other hand, I even never gave a try 

[vshaulsk]

Thanks Christian and Half_life

I will look into both options.  Currently my clients only use the webaccess part for email and not a local email client, but maybe I should add one.


Now do you have any idea how to migrate the local user profile on each machine to the new domain?  I don't want the users to loose their settings, favorites or any folders they might have on their desktop.

[half_life]

Thanks Christian and Half_life

I will look into both options.  Currently my clients only use the webaccess part for email and not a local email client, but maybe I should add one.


Now do you have any idea how to migrate the local user profile on each machine to the new domain?  I don't want the users to loose their settings, favorites or any folders they might have on their desktop.

Sorry,  I wasn't clear.  Imapcopy accesses on IMAP store and copies its contents to another IMAP store.  They are physically stored within a mysql database and the version change precludes just copying over the database.  Also there would likely be disconnects between user ids.

[half_life]

On closer review,  creating a script to automate the imapcopy between two machines will be easy.  The user dump from the migration tool includes the necessary information in a convenient csv file.

I am also looking at inserting my users last 4 digits from their social security number (available to me in our financials database) as a temporary password since the process requires you to change the password.

I have prepped a virtual machine to hold my current email stores (Zarafa) so that all I have to do is copy over the /var/lib/mysql directory when the time comes.

My general plan is to upgrade my production 2.2 to a 3.0 system over the weekend but not deploy it into the gateway role. I intend to wait for the 3.2 gamma release and upgrade to that on the same virtual machine (the developers have stated that there will be a direct upgrade path from 3.0 to 3.2).

I will then shut off mail reception on my production 2.2 system and do the email migration that I described above.  Only then will I deploy the new server.

I will use the available time between this weekend and the 3.2 gamma to debug the process by performing it a few times while timing it.

[vshaulsk]

Half_life I am very interested in what you are doing.... since this is the exact situation I am in as well.  I would love for my users to not loose their emails.

Now to the second part of my question:  Are your users using windows 7 machines or something else?

If they use windows 7 machines and you are not using roaming profiles.... how are you planning on switching them to the new zentyal version?  When they log in the first time a new profile will be created on the windows machine domain/user  so the clients will loose their previous settings or data on the desktop.

[half_life]

The standard desktop in my environment is Win7 64bit.  I currently have a separate Domain Controller with a botched up domain name (GLTC_DOM) that I inherited.  My intent is to rebuild the domain around Zentyal.  In your case, you might be able to join Zentyal to your existing domain as an additional controller.  Afterwords you could shift FSMO roles if you are taking the other system out of service.