Best practice in maintaining OTRS configurations

[lleto]

Hi,

I have been assigned with the task to manage an older OTRS system and have a few questions.

What is the best practice people have found to maintain a system? Over the years (about 5) there was quite a bit of ad-hoc management so there are lots of old users, queues no longer used, lots of mailboxes. In short there is some more insight now into how to configure OTRS to better fit the company and we want to get rid of the mess. Is it possible to upgrade the existing data onto a new config and how would that be done or better to start with a clean system, but then where to leave the history?

Are there any pointers on people managing and updating older systems with lots of history?

Thanks,
lleto

[crythias]

if history is relevant, you can't delete the attached elements (queues, etc)..

In theory, you *could* duplicate your environment to a different, archival server (without email fetching). This can help with preparing for disaster recovery.
Next, after backing up your database again on the production server, you can delete old, closed tickets via generic agent. and make sure via search or generic agent that no other tickets are attached to:
queues, old users, or emails. You may choose at your own risk (which should be minimal specifically because you can't find them attached to tickets) to delete the unused users or queues directly from the database. (I don't recommend deleting stock queues, though.)

This is *one* way to handle this. It should make *general* sense but if it doesn't make sense to you, don't do it. I am not and can't be held responsible for your data, but this should be one of the (imo) safest way to do this.

If you do this, though, note that you will not have a practical ability to merge the two databases back together, due to ticket duplication and dependencies you're deleting on production.

Also, if you do this archival second database method, you may want to make sure group membership on the archival server for all users is read only.

If customers have web access to tickets, they will also lose their history for tickets you delete. Consider if this is relevant.

[VeteranNewbie]

A suggestion;

1. Create a duplicate server/database (perhaps on a VMware or Windows Hyper-V machine: there are tools to virtualise existing HW-based servers) and then snapshot it at various intervals as you delete 'unnecessary' items. This means that at any point if you discover you have deleted something critical, you can rollback to the previous snapshot.

2. When you have it working how you want it you can export the config from OTRS and dump the data from your database.

3. Then create a new clean OTRS install, and import your config and database content from the duplicate to the new install. Test the new install yourself to ensure it is in production-ready state.

4. Turn off the existing production server (or better, just disconnect it from the network and leave it running) and use DNS and/or renaming to replace it with the new server.

5. If you find out that it is all horribly wrong, just unplug the new server and plug in the old production server. If it all works to plan, then after some time you can delete the duplicate virtual machine and re-use the production server for something else.

The critical element in all this is TIMING. The longer you take to get the system in the state you want, the more the production system diverges from your duplicate (you've basically forked your two environments). So planning what you're going to remove beforehand, and setting up your duplicate and new servers beforehand, might enable you to do this over a weekend outage, for example. It depends how complex your system is, and how much downtime you have available, and perhaps other things peculiar to your environment.

In general, I would advise you to never use your working production system to make irreversible changes, if it is at all possible to avoid it!

Good luck.

[lleto]

Hi,

thanks for the tips. I was hoping some more advanced tools

My idea to approach this was more or less:
- backup old server database
- install OTRS on new server
- create new queue structure
- create bogus user called 'old employee'
- run queries on old database to:
a) fit tickets into the new queue structure
b) assign tickets from users no longer active to the 'old employee' id
- import database in new otrs

With respect to a and b:
a) I should probably change the queue_id to match the newly assigned queue for tickets. So first create a table:
old_queue_id == new_queue_id
and so on.

Then find all queue_id fields in database that related to ticket or mail routing:
mail_account->queue_id
system_address->queue_id
ticket->queue_id
ticket_index->queue_id

There are a couple of other locations for queue_id, but these relate to specific settings for that queue, so not important. Now create a sql query that updates the queue_id according to the table.

b) I've looked at the database. Potential fields that can hold user ID's are:
article->create_by
article->change_by
article_attachment->create_by
article_attachment->change_by
article_flag->create_by
article_plain->create_by
article_plain->change_by
article_sender_type->create_by
article_sender_type->change_by
article_type->create_by
article_type->change_by
auto_response->create_by
auto_response->change_by
auto_response_type->create_by
auto_response_type->change_by
calendar_event->create_by
calendar_event->change_by
customer_company->create_by
customer_company->change_by
customer_user->create_by
customer_user->change_by
faq_attachment->created_by
faq_attachment->changed_by
faq_category->created_by
faq_category->changed_by
faq_category_group->created_by
faq_category_group->changed_by
faq_history->created_by
faq_history->changed_by
faq_item->created_by
faq_item->changed_by
faq_voting->created_by
follow_up_possible->create_by
follow_up_possible->change_by
group_customer_user->create_by
group_customer_user->change_by
group_role->create_by
group_role->change_by
group_user->create_by
group_user->change_by
groups->create_by
groups->change_by
link_relation->create_by
link_state->create_by
link_state->change_by
link_type->create_by
link_type->change_by
mail_account->create_by
mail_account->change_by
notification_event->create_by
notification_event->change_by
notifications->create_by
notifications->change_by
package_repository->create_by
package_repository->change_by
personal_queues->user_id
queue->create_by
queue->change_by
queue_auto_response->create_by
queue_auto_response->change_by
queue_standard_response->create_by
queue_standard_response->change_by
role_user->create_by
role_user->change_by
roles->create_by
roles->change_by
salutation->create_by
salutation->change_by
service->create_by
service->change_by
service_customer_user->create_by
signature->create_by
signature->change_by
sla->create_by
sla->change_by
standard_attachment->create_by
standard_attachment->change_by
standard_response->create_by
standard_response->change_by
standard_response_attachment->create_by
standard_response_attachment->change_by
system_address->create_by
system_address->change_by
ticket->user_id
ticket->create_by
ticket_flag->create_by
ticket_history->owner_id
ticket_history->create_by
ticket_history->change_by
ticket_history_type->create_by
ticket_history_type->change_by
ticket_lock_type->create_by
ticket_lock_type->change_by
ticket_priority->create_by
ticket_priority->change_by
ticket_state->create_by
ticket_state->change_by
ticket_state_type->create_by
ticket_state_type->change_by
ticket_type->create_by
ticket_type->change_by
ticket_watcher->user_id
ticket_watcher->create_by
ticket_watcher->change_by
time_accounting->create_by
time_accounting->change_by
user_preferences->user_id
valid->create_by
valid->change_by

Wauw, long list. Should I change all of these to the new 'old_employee_id' if the create_by, change_by or user_id = id of employee no longer working with OTRS?

Appreciate tips and tricks and yes I am aware that I am responsible for my data

Lleto.

[crythias]

Have fun.