Our BlackBerry implementation is going to be taking place on Friday afternoon/evening (and
of course it'd be the first Friday evening in months I had something previously planned - a nice dinner with the CDL and her Bear), so this week has been a fairly hectic swirl of meetings and preparation.
Since this whole thing is connected into the email infrastructure, I have to do most of the prep (and I'll be managing the service anyway). One of the preparation steps is ensuring that the BlackBerry service account has the appropriate rights to all the user accounts that will be using the service. While it's very easy to give a bunch of users access to a mailbox (you put them in a group, and then give the group rights to the mailbox), giving one service account access to a bunch of user accounts is a bit more complicated.
The most convenient method is to put the accounts into their own "
Organisational Unit" (the diagram shows how a Windows domain looks like a tree - all the objects in the left pane are OUs), and then you give the service account the correct access to all the user objects inside that OU. Unfortunately, in our Windows domain, we don't use many OUs for this kind of purpose. All the domain users are in a single OU, called, OMG, "Domain Users". All the users in this container get a bunch of policies associated with their accounts, so that they get the correct settings when they log on to their workstations. My suggestion to get around our problem was to create another OU inside the Domain Users OU, so that we can put our BlackBerry users in it - they will inherit the policies from the level above, while granting the service account access to their mailboxes. Easy.
But apparently not. I went to one of the Windows admins today to see if we could implement something like that. According to him, "If we do this, then we'll have to create separate little OUs for every application with this kind of issue." So? Since this is the
first one in four years, I don't see us suddenly getting hundreds of little OUs proliferating. And, "I don't know if this will work anyway. I'll have to talk to $OTHER_ADMIN, who knows about this stuff." Um, I'm sorry, you're a
Windows domain admin, and you don't know how OUs work? Jesus christ. Ok, in a team, you usually have your little areas of interest and speciality - that's how I've ended up as an email admin in this job - but just because you're the "server hardware" guy, you should still know the
basics. Not to mention the fact that
I know what I'm talking about there. And not to mention the fact that $OTHER_ADMIN is semi-retired, and only works two days a week. Also, getting
him to do anything even slightly different is almost impossible, no matter the logic - if it needed to be done, surely it would have been done
before (so what if you haven't experienced that situation previously). [This is the guy who is still using robocopy and a manually-edited script to push out server updates - totally ignoring any of the MS and third-party tools that work well and more
efficiently to do the same job in an automated fashion. No wonder my servers are missing about 15 patches at present.]
You know, one of the aims of our divisional restructuring exercise at present is to break down the "siloing" mentality in the organisation. I think it's bad enough that there's a split between the mail and systems/domain admin teams. I'm just fairly flabbergasted at the fact that there is such a division
within that team. That's not to say that I don't think that the admin I was chatting to shouldn't consult with $OTHER_ADMIN when making a change to an established structure, but he should at least know it's
feasible, and, if not, be able to give me some reasoning as to why not.
Thank you for ventage. I'm tired, and it makes me grizzly. Everything is going along fine, and this hiccup is not going to stop the pilot going ahead - I'll just add the service account to each user manually for our trial period, at least until the Windows admins make up their bloody minds.