Hi All,
My question is both hypothetical and practical. I’ve got RT deployed in my
I.T. department doing what it does best and it’s working well. I’ve put
feelers out to some other departments that I think could benefit from RT to
see if they would be interested in having it setup for them. I am finely
getting some positive responses so I’m looking for some guidance on
deployment options. I am trying to decide if I should share an instance of
RT among 1+ departments or create a new instance of RT for each department.
Hardware is not an issue either way, nor does it look like the traffic
volume will be an issue. These are all internally created tickets with no
Internet access to my RT instance. If Internet access were required then a
separate instance of RT would be desirable.
So what I am looking for from people who have either had this issue or
thought about it is: what factors you would take into account when deciding
on 1 or more instances of RT and why.
Thanks,
James
I work in a university computer center. We try to set up
an instance per department or other large unit (e.g. college)
on request. Part of it is, I can hand the instance to an
admin and say “have fun”. They can then handle new users,
privs, new queues, etc. (I have to connect email addresses
to new queues, though.)
There are many ways, all good. It partly depends on how much
control a given unit wants over it’s RT instance, to a lesser extent
the security of isolating instances, and the nuissance of wanting
to transfer tickets between instances.
A downside of many instances is that you can’t transfer tickets
between them, and you need someone to take care of each instance.
We do the sysadmin work, but the dept has to deal with adding
consultants, etc.
bobg
Hi;
We use one instance for 40 or so departments across 5 different sites in
2 countries …based on queue/s per department
Worked well for the past 4 years.
With the right permissions , the look and feel as if it were different
instances.with the added bonus tickets can be shipped between different
queues and the maintenance is simpler.
Creating new queues, queue cf’s, watchers and users are managed by the
sysadmins in the different sites, scrips are created and managed
centrally by me and my team.
Regards;
Roy
james machado wrote:
I have had to think about this a lot. Maintaining one RT with customizations
for lots of different groups can be challenging. Maintaining multiple RT
instances and trying to keep some customizations in sync across those
instances can also be a bit of a pain.
So what it comes down to for me is risk. I can’t have my externally facing
customer service queues being screwed up by customization for my internal
queues. So for me customer service gets its own instance and everyone else
gets another instance.
-ToddOn 1/9/08, james machado hvgeekwtrvl@gmail.com wrote:
Hi All,
My question is both hypothetical and practical. I’ve got RT deployed in
my I.T. department doing what it does best and it’s working well. I’ve
put feelers out to some other departments that I think could benefit from RT
to see if they would be interested in having it setup for them. I am finely
getting some positive responses so I’m looking for some guidance on
deployment options. I am trying to decide if I should share an instance of
RT among 1+ departments or create a new instance of RT for each department.
Hardware is not an issue either way, nor does it look like the traffic
volume will be an issue. These are all internally created tickets with no
Internet access to my RT instance. If Internet access were required then a
separate instance of RT would be desirable.
So what I am looking for from people who have either had this issue or
thought about it is: what factors you would take into account when deciding
on 1 or more instances of RT and why.
Thanks,
James
The rt-users Archives
Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com
Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
–===============1115171146==
Content-Type: multipart/alternative;
boundary=“----=_Part_8390_1032883.1199978446926”
------=_Part_8390_1032883.1199978446926
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
I have had to think about this a lot. Maintaining one RT with customizations
for lots of different groups can be challenging. Maintaining multiple RT
instances and trying to keep some customizations in sync across those
instances can also be a bit of a pain.
So what it comes down to for me is risk. I can’t have my externally facing
customer service queues being screwed up by customization for my internal
queues. So for me customer service gets its own instance and everyone else
gets another instance.
Interesting. For code customizations, I have my paths set up
so that a given instance gets a base part (governing the core RT version),
a common part for all instances (of that RT version) where I put _vendor
files, and a per-instance part. Any customization I want to apply
to all instances is easy, and I can still have per-instance differences.
Of course, if you mean customizations in the RT config file or in
the database, this doesn’t help.
bobg
To all,
I work in the IT division and we only have one instance and it is used
primarily for keeping track of requests for maintenance, custom work,
etc. for our many (over 50 queues) software applications. I have
developed an approval (ticket review and prioritization) and QA
(Acceptance testing) “workflow” set of scrips and templates and it works
great. However, there are so many other areas here where RT could be
helpful. Being in Tech Services and the Sys Admin of our only version of
RT, do I keep it to myself or spread the joy? From that perspective, I
have to agree with Bob Goldstein. It really depends on the priorities of
your department. Does the company have other departments where someone
would be capable of administrating another instance of RT? Are there any
chances that tickets from one instance might want/need to be transferred
to another? What kind of differences/customizations would be needed
between instances? I suggest doing an analysis of those subjects and any
others you might come up with and prioritize their values and decide
from there. I’m going with the one instance. That way, I can control
what customizations are made to our one instance. If I ever get a
department that has radically different needs and requirements, then I
might want a different instance. For me, redundancy is usually a
maintenance nightmare and I don’t like designing or creating unnecessary
work. But hey, that’s me. Good luck!
Kenn
LBNLOn 1/9/2008 3:53 PM, james machado wrote:
Hi All,
My question is both hypothetical and practical. I’ve got RT deployed in
my I.T. department doing what it does best and it’s working well. I’ve
put feelers out to some other departments that I think could benefit
from RT to see if they would be interested in having it setup for them.
I am finely getting some positive responses so I’m looking for some
guidance on deployment options. I am trying to decide if I should share
an instance of RT among 1+ departments or create a new instance of RT
for each department. Hardware is not an issue either way, nor does it
look like the traffic volume will be an issue. These are all internally
created tickets with no Internet access to my RT instance. If Internet
access were required then a separate instance of RT would be desirable.
So what I am looking for from people who have either had this issue or
thought about it is: what factors you would take into account when
deciding on 1 or more instances of RT and why.
Thanks,
James
The rt-users Archives
Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com
Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Here at Koumbit.org we’ve setup an extra RT instance for a fellow
organisation/partner that needed the resources. It’s a seperate
instance because I didn’t feel confortable giving them user access to
our RT.
I would never consider deploying another RT for ourselves, too much
trouble. Seems to me Queues and Groups can do all I need.
Now of course if you need nifty customizations like graphical
modifications or really particular behaviour, you might need seperate
instances, but in my experience, it’s too much trouble.
A.
Computer science is no more about computers
than astronomy is about telescopes
- E. Dijkstra
signature.asc (189 Bytes)
Just wanted to say thanks for all of the feedback. Gives me something more
to think about 
James