Here is the foundation for this post and why you need to read this if you have two teams. One specific to AD (Active Directory) and the second team who owns SharePoint AND is not IT (about 99% of the time). This more often than not happens in large organizations or in companies that have extremely small IT staffs who are wearing too many hats to deal with yet another “program” such as SharePoint. There are certain things AD is needed for when it comes to SharePoint. More explicitly, there are pieces of SharePoint that are deeply integrated with AD and when there is a disconnect between the two… Bad things happen! When these bad things happen, the end users suffer. When the end users suffer, you have one of these at your door.
(Homer being chased by an angry Mob. Thanks to Fox Television. This is not my work. Watch the longest running sitcom ever on Fox. Got to give credit where credit is due.)
Here is a great example I have had an email thread with one of my peers about this very subject. I have changed the names and such to protect the innocent.
Example 1
“I am consulting to a very large international company. In this company the AD group is a global group and doesn’t talk much to the SharePoint group. They have established the following Practice.
Suppose I start my life out in Europe. My AD user ID will then be EUROPE\Smith. Now I move to the USA. They now change my ID to NA\Smith.
So… They let the SharePoint group know through some feed periodically of all the users. The SP group now makes sure that all the users in the feed are available as user in SP, while the people who no longer appear in the feed get removed. Below is a detailed case study that I put together:
================================
From the SharePoint perspective, the actions taken “automatically “are equivalent to creating a completely new user id, and deleting the old one.
Automatic Scenario (Smith as an example)
1. AD alerts SharePoint of a new user id (NA\Smith)
2. AD no longer tells SharePoint that the old user id is valid (EUROPE\Smith)
3. SharePoint script figures out that (EUROPE\Smith) is no longer valid ID.
Therefore SharePoint Script removes the user ID (EUROPE\Smith).
4. RESULT: (EUROPE\Smith) no longer has access to the objects that he once did.
The short term solution is to run a server side operation that moves the user ID from EUROPE\Smith) to (NA\Smith)
================================
This took me over a year to uncover why we were having issues with some people.
My questions to you is: Is it normal practice in large AD implementations to change a user? (Say from a EUROPE Domain to a NA Domain)”
Example 2
SharePoint Team: Hi, we are going to install SharePoint <newest version>. We need <insert number above 6 here> service accounts.
AD Team: What!? *Crawls off the floor and back into their chair*
SharePoint Team: We want to install using best practices. Oh and the LDAP account. We need to give it elevated rights in AD. We want SharePoint to push AD several fields the governance council decided should be self-service.
AD Team: WHAT!? *Starts hyperventilating in a brown paper bag*
SharePoint Team: Yes, it needs to have the ability to Replicate Directory Changes and also Create Child Objects and Write All Properties as well.
Announcer: 7… 8… 9… 10… the AD Team is out for the count. there is no recovery from this one folks. Smoke is coming out of their ears. There is nothing left but the wrap up… *continues to drone on with sad opera music blaring in the background*
My Thoughts on the Matter
I could very easily dig into my past and find other examples, but i think i safely made my point. More often than not this deals with large companies with serious communication, people or cultural issues. Some is because they grow by acquisition, others from pure organic growth that was faster than the culture could adapt to. The concept of an IT getting over burdened by the number of application and having to create “Power User” teams to fill the gaps where IT cannot is becoming alarming as well. Companies have a hard time understanding IT can be only slashed so many times before it loses its effectiveness as a unit. A majority of companies i have worked with, spoken to, interviewed, etc. have skeletal staff in IT, wearing multiple hats and responsibilities over many different applications, network devices, and more. These stalwart individuals out of a sense of duty/loyalty, will do their best to make it work placing duct tape over gapping wounds out of fear of losing their jobs. I seriously digress, I am sure many are well aware of this issue, but I felt it necessary to defend IT staff after poking fun of them in Example 2.
To the IT Staff. I would highly recommend relooking at your Standard Operating Procedures (SOP’s) that deal with AD objects. As you saw in example 1 they were just deleting a user object in one domain and creating a new one in another domain. This is becoming less and less of an option as Microsoft is tying more and more of their products to the AD user objects. From exchange mailboxes, Lync accounts, to SharePoint user profiles, AD objects are being relied on as a defining factor in these and more. The level of end user impact will now be very noticeable and will cause added undue stress internally. It would be my recommendation to “migrate” a user account from the Europe domain to the Americas domain as in the example above. (Example 1) Secondly IT Staff, if you are going to utilize your power user teams to offload applications such as SharePoint, you will need to have a certain level of trust with that group. This will be necessary to not have issues such as the above example (Example 2) surface and you feel blindsided.
To the Application Teams (Power Users). Being in this position can be/ is a two edged sword. You have been identified as someone who is capable of managing SharePoint, but within the same regard, you are not IT. This place, at times, can feel like your in limbo. My suggestion to you is be sure you have all the information you can gather, before you go to your IT team for a request. If you are asking for elevated privileges for your LDAP service account to allow My Site’s to make changes to AD. Be sure to gather the information IT will request/need to make an educated decision with. Also go in with the understanding the IT staff is going to be hyper-sensitive to bringing others into their realm to assist them. They desperately need the help/staffing, but are always first in the line for the firing squad when the economy is showing itself to be tough. Another thing to keep in mind, unless you worked in IT previously, you may not always garner the support of IT on everything you request. Understand, they from a technological perspective, see the bigger picture and how things may or may not work in the whole when you do make requests.
To both sides of the equation. Everyone has something to offer, check the ego’s at the door when you meet. Make sure you meet, i have been with clients who had both teams whom almost never spoke to each other at all until something hit critical mass. When meeting, ensure you take all information available to you to ensure the other team is adequately informed, especially when decisions need to be made. Understand both teams are trying to reach the same common goal. There is no way a company can/should replace IT staff with power users. This being said, lower the defensive shielding a bit as this fear has not solid foundation. (or shouldn’t) IT as the number of applications increases. More importantly as SharePoint continues to infiltrate into the deeper recesses of your business, you are going to need help. Find ways to work together and not make counterproductive choices that will negatively effect the other team.