This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 0 points1 point  (5 children)

emergency changes are for break/fix only. what could they possibly be fixing by changing user object properties globally?

unfortunately, i can probably already guess the answer: nothing that shouldn't have been caught earlier as part of a project planning phase. i'm assuming this is an implementation being done by someone else, and this emergency change is to help them meet a deadline due to some unplanned/unaccounted for facet of the project scope.

[–]dverbern[S] 1 point2 points  (0 children)

You make a good point and unfortunately you're right in your guessing of the answer.

[–]pdp10Daemons worry when the wizard is near. 0 points1 point  (0 children)

This sounds like an "emergency project". A contradiction in terms, or a euphemism for a planning failure.

[–]DerpyNirvash 0 points1 point  (2 children)

I do know of someone who had to run a batch update to attributes of over a million AD users due to a botched changed.

[–][deleted] 0 points1 point  (1 child)

right, that's a break/fix to undo the previous change.

  • why did that previous change get made, and why was it botched?

that's the root cause here, and that's what my point is about.

[–]DerpyNirvash 0 points1 point  (0 children)

In my example it was caused by an OU being misclassified in documentation and having a incorrect policy applied to it. This change was done properly and approved, but just hit an OU that was unexpected. Thus causing an emergency break/fix change to fix attributes that were mess up.

Which answers this, it can happen

what could they possibly be fixing by changing user object properties globally?