That sounds like the best course to me, it doesn't seem from they way my organisation uses ITIL that it's a problem, as it is known whats wrong and it's known how to fix, I have generally only seen problems used when the root cause isn't known, or that there is a workaround but the issue is still there, changing permissions would be done through a change request from everything I have seen.
ITIL Problem Management Question
- Thread starter A[L]C
- Start date
That sounds like the best course to me, it doesn't seem from they way my organisation uses ITIL that it's a problem, as it is known whats wrong and it's known how to fix, I have generally only seen problems used when the root cause isn't known, or that there is a workaround but the issue is still there, changing permissions would be done through a change request from everything I have seen.
My view is that it would be a problem while the scope of the issue is reviewed and a fix plan identified. Changes made to the server permissions as part of that fix would be under change management.
I suppose it entirely depends on what is "wrong" with the server permissions, if it requires investigation, to decide on what the permissions need to be changed to then yes I think that does make some sense, if it's known what needs to change and to what already then it would just be a change.
Well, ITIL is a framework. I think it can be helpful if you just take what you need from it. There are quite a lot of common sense practices in v3 that should already be in place, but if they aren't, it's a good excuse to get them implemented and then flag up to management that you're ITIL compliant for XYZ area.
But yeah, a lot of these frameworks and systems can be frustrating and almost feel like a cult sometimes. I see the value in some parts of them but a workplace that stuck rigidly to the whole system regardless of how suitable for the team(s) it is would get annoying quickly.
Soldato
- Joined
- 11 Sep 2009
- Posts
- 14,064
- Location
- France, Alsace
Haha sounds about right.
Although ITIL states that regarding potential problems, it's hard to nail down really. You have to look at the impact of the possibility and as such, when it's permissions related I would probably be inclined to agree. Although, there is no RCA required, as it's a configuration issue, so you know what you need to do to fix it, which is to issue a change request to alter the permission structure.
This isn't an incident, so it's not ITIL, it's just poor configuration (which granted, in some cases can lead to incidents), but this isn't one of those scenarios.
There is no root cause, or fix. There is is best practice, therefore, again, not an incident and not really governed by ITIL
In a normal scenario, you would raise a change for CAB with a plan to rectify, implement and back out if necessary, and that would be IA'd with the relevant teams (Server support, security, AD guys for ACLs, etc).
There is no root cause, or fix. There is is best practice, therefore, again, not an incident and not really governed by ITIL
In a normal scenario, you would raise a change for CAB with a plan to rectify, implement and back out if necessary, and that would be IA'd with the relevant teams (Server support, security, AD guys for ACLs, etc).
Soldato
- Joined
- 6 Nov 2002
- Posts
- 9,921
- Location
- London UK
Raise as an incident/problem if impacting service, otherwise would have it logged on a risk register with a Configuration Management change request being raised to mitigate.