People get married and divorced
This request is being reviewed.
Luis Londono commented
Is this being released any time soon?
Vladyslav Velychko commented
AdminHeather P (VP, Products, GFI) commented
Thanks for the feedback and use case Howie.
I'm glad to see this as under review. I have two users on one of our Kerio Cloud servers that I have to rename. To do this, I have to work with someone at Kerio who has access to the server VMs hosted by Kerio Cloud. This is the kind of thing that make me want to move our servers out of Kerio Cloud. I don't have root access to my servers, so I have to rely on someone to be available to do the change for me. That's ridiculous!
Patrick Helm commented
We need a way to change the username in the GUI that also creates a login alias so devices still work until they are able to make the change.
By doing this, via the GUI for an admin, to change the email address/login name from first.old to first.new it should also keep all the shared calendar DB and invitations linked.
The root level access, does NOT work in this way as the new user from memory with the old messagestore is not seen as being the owner of the old calendar invites and thus they are locked.
Thanks Kerio - please keep looking into this.
Also, some cloud hosted kerio options (i.e cloud hosting solution providers) don't allow us root access to do this ourselves.
Jérôme Haegeli commented
Sorry but this not a solution... this is the normal behaviour !
The goal was different and sorry but I repeat one more time a "smart" solution:
This feature requested concern the same issue of this other one:
Changing the name is the same request has we can set a DEFAULT EMAIL who is ALWAYS used by Kerio.
The AD credential rest but the email address can be changed !!!
Below, my explanation to Kerio support about this issue:
To "rising above Exchange" like you say on your homepage, only this feature is missing:
In case of using email address aliases, Availability to set the default email address
This is common in organization who the AD credentials aren't the same as the public email address.
This for two reasons:
2) When you receive an appointment to your email alias (firstname.lastname@example.org),
the email address used for replying "accepted" is the "account" email address (SAMaccount1@domain.com).
This may duplicate entries to the organizer has he see email@example.com not responding and a new SAMaccount1@domain.com that has accepted...
Imagine with many people...
This is normal and expected behavior. There is no such thing as "good e-mail address" - you can have hundreds of thousands of aliases, so how does Kerio know which one is the "good" one?
I can't understand why Kerio can't used one of these item below instead of the account name:
- Kerio-Mail-Prefered-Address (where is really used this attribute ????)
- AD email attribute
- Using the first alias from Kerio-Mail-address (that not include the account address !)
And why a Kerio-Mail-WebToReplyAddress attribute exist and not a Kerio-Mail-DefaultAddress one ?
Is this way, users can continue to use their AD credential and all is working fine.
Other people with the same issue from 2008 to now...:
But in this way, users need to use the email address instead the AD credentials, who confuse them....
Here's the old method.
Delete the current account, but do not delete their data. Stop Kerio Connect. Go into the Kerio store, and rename the user's mailbox the match the new user name. Start Kerio Connect. Recreate the new user account using the new user name that matches the name you just gave the user's mailbox. Kerio Connect will match the new account to the renamed mailbox. It's also adviseable that you reindex the mailbox after this. Unless you know the user's password, you will need to assign a new temporary password to the account, and then let the user change it to what ever they want. They will then have to reconfigure all of their devices to send and receive using the newly renamed account. We should also add an alias for the old user name to resolve to the new one so that no incoming emails are lost.
That's the procedure. It's cumbersome, and it means that service has to go down for a few minutes while we perform the procedure. This relegates the task to late nights, or early mornings, and if you don't have root access to your server, you have to have Kerio do it. Kerio Cloud support would have to have cloud ops do it, which means that the procedure gets queued up along with all of their other tasks. It's. A . Pain.
I'm not trying to debate anything. The method I've described is the only one I know. I genuinely want to know the "old method" to which you're referring. I'm also not sure what which "new solution" is to which you're referring. I'm sorry if I'm being dense, but I am honestly unclear as to what you're referring, hence my questions.
I'm also sorry you're somehow taking my notes as some kind of a challenge - that is certainly not my intent. I'm only trying to contribute my experience to the conversation and am interested in what others like yourself are willing to share, hopefully to all of our benefit.
Tony, I'm not going to debate this here. If you have worked with Kerio Connect, then you know what "old method" I'm referring to. It's cumbersome, but it does everything. This new solution leaves behind remnants of the old account configuration. That's what I'm referring to as "half way". My point still stands. Kerio can do better. This is what I have come to expect from them after 10 years of working with Kerio products.
To which "half-way solution" are you referring? If your "old method" is different from what I described, I'd love to hear about it. I'm not advocating the method I use as preferable, it's the only way I've ever known to accomplish this task.
This is a half-way "solution". I won't use it. I will keep using the same old unnecessarily difficult method because the old method actually makes the change fully. Kerio CAN DO BETTER than this. This has been open over 7 years. That alone is not acceptable, and neither is this "solution".
Please note that this is to change the root account name, not just the display name. This is important because that name is referenced and displayed when using ActiveSync or EWS. The most common instances are for marriage, divorce, or when we change a person's name to/from a generic position, e.g. reception, intern, etc.
Currently, the only way to do this with local accounts (not using AD/OD), is to: record and delete any aliases to the account, remove the account via the Admin console (making sure to leave the data on the server), stop the server, rename the local folder to the new name in the "store" directory on the server, start the server, create a "new" account using the new account name, then login to that account via WebMail. The "new" account will then read the existing data and the user is ready to go. We then create an alias with the old address so mail to both the new and old addresses comes to the account, along with any other previous aliases for the account.
I agree that it's pretty frustrating that this request is still outstanding after so many years (and votes). I'm cautiously optimistic that with a new mindset from GFI (and hopefully increased development resources), features like this may now be addressed.
Bud Durland commented
I just got an automated e-mail from Heather describing the 'acceptance' criteria. Unless I'm mis-reading it, they are gonna miss the mark by a mile. I need to be able to change someone's login id (user name), and have it be changed EVERYWHERE in the mail server.
Peter Szabo commented
I came across this issue when we had to change one of our users login name in the active directory.
With that change we had to change his email address. I thought this is a basic feature and it is easy to change the email address and name in Kerio.
It is a bit frustrating that this ticket has been opened more than 7 years ago and nothing happened...
AdminHeather P (VP, Products, GFI) commented
Thanks for the comments. Whilst this seems like a simple request, it's actually more complex than you would think, and requires a change in the way we identify each user individually. We hope that some of the architecture changes over the next few months will enable us to do this.
Jerome Bourguignon commented
this seems fairly simple and would greatly help admins (the ones that prescribe your solution)
Kerio don't care... Essential features are
Joerg Tennstaedt commented
Pleeeeasse, i need that "normal" Feature because our female User are often get married, or divorced and it´s driving me insane to delete the user in other user.
This solution brings often problems with appointments
SIavash Khazaei commented
and it most work on changing default email address too/...please add
Will O'Neal commented
6 years on the request list.