I have been asked this question a lot lately so I thought I would throw something up. Now I can tell you I am not in love with writing this yet because 2010 RTM is still fresh on the streets and I am never happy until I have at least 50 clients running 2010 farms to get a feel for what is really going on. But Shane you have been using the early builds forever why don't you have this all worked out? Because until the bits went RTM some of the account issues were touch and go so I used test farms with one account way too often. :( It was a crutch but got me through those early builds. So get over it.
Now when I was first asked the question I did the responsible thing and started asking questions of people that were smarter and to be honest better looking than me if they had any ideas. Unfortunately none of them did so I then I asked Todd who had actually also been talking to Spence about said topic. (For the record neither of them is better looking than me.) They had some input that went along with what I was thinking. I also got real crazy and read the TechNet article on Account Permissions. While it looks really good it is way too detailed and most of you aren't going to read it. So here is what I am doing these days.
Running setup.exe/farm configuration wizard(grey wizard) – In 2007 this account was crucial for you to get correct. You needed a dedicated account. In 2010 this is not as important thanks to the introduction of the passphrase. The key thing about this account is it must be a domain user and a local administrator on all of your SharePoint servers. For the SQL Server it needs the SQL roles of securityadmin and dbcreator. It does not need to be a domain administrator and it does not need to be a SQL server administrator. This account could be your account but I still like to defer to my 2007 style and create a dedicated sp_admin type account for this.
When you get to this screen:
You need to specify what we call the farm account. I like to use domain\sp_farm but you can do as you like. This account needs to just be a regular domain user. This account for right now doesn't need any other access. SharePoint will use the install account you are logged in with to make this account a member of some local server groups and give it the dbcreator and securityadmin SQL roles. This account is then used as the central administration application pool account and the SharePoint timer service. Now something to keep in mind. If you are going to configure profile imports read my last blog article, this account has to be a local administrator on the SharePoint server when you provision the service and needs some weird AD permissions to get your started. Akward.
When Central Admin opens for the first time you will probably use the initial farm configuration wizard (white wizard) and you will be prompted to setup a managed account as shown here.
This account will be the default account for the different service applications and will be the identity of the service applications app pool account. This account is just a regular domain user with nothing special for you to do.
Now when you create your first web application you will need to create a new application pool. I recommend that when you do this you create a dedicated account for your application pool. Every unique app pool I create I always use a unique account. This account is just a regular domain user. SharePoint will give it the permissions it needs.
When you start to configure your Search service application you should change the default content access account, you do this from the manage service applications screen and click on the search service app you want to change. By default it will be the account you used in step 3. What you want is to change it to a dedicated account that has read, and ONLY READ access, to all of the content you want to crawl. If you don't you will end up with trash in your index you don't want.
In the same train of thought when you configure your user profile service application connection you will need to specify an account. This account will need some funky AD rights so using a dedicated account isn't a bad idea.
That should be more than enough to build a decently segregated farm from an account perspective. Some people will use less some more so take this for what it is.
One struggle people run into when they do least privilege type installs is they struggle how to get Windows PowerShell to work properly. They do cmdlets like get-spsite and get weird access denied responses. The reason is a lack of rights in SQL Server. Instead of me telling you how to get those rights I will give you a link to Zach's post on the topic. It is a quick read and will make your life easier.
Anyway, I hope that helps. If you have any feedback let me know. I am sure I will insult someone with my over simplicity of this post. :) Or I missed something simple.
Shane – SharePoint Consulting
So I keep smashing my head into this and it drives me nuts. So I am going to try to throw together some quick nuggets. I have gotten this to successfully work about a dozen times so I have hopefully seen all of the craziness. I have also worked with Todd Klindt to compile some of these notes.
The first one is for goodness sakes read this TechNet article. http://technet.microsoft.com/en-us/library/ee721049.aspx If you read it slowly and do everything it says you can do very little wrong. But no one wants to read it so here are my notes.
The farm account HAS TO BE A LOCAL ADMINISTRATOR. I am sorry but there is no way around this right now so quit trying to avoid it. Having a problem figuring out what account is your farm account? I can help with that.
- Central Admin > System Settings > Manage services on server
- Scroll down and find the User Profile Synchronization Service and click Start
- You will see an account listed. This is the account that must be a local administrator account
- If you are adding this account to the local administrators group for the first time right now you should reboot your server after you finish. If you don't you will get some nasty DCOM errors that will not go away until you are a local admin and reboot.
- The farm account has to be able to logon as a service. By default a local administrator can but just in case you have locked down your server extra tight this might come up as it did for Todd the other day.
- This same farm account has to have the Replicate Directory Changes permission in active directory. This is also not optional. I also ran into an issue when the forest functional level in active directory was still 2000 but I cannot find the notes on that. Something about this Replicate Directory Changes not being possible.
- An oddity I don't really understand but have seen once. In one case I had to log onto the server as the farm admin account one time before I was able to get the service to start. Most of the time this is the case but once it was. Very odd. This blog post had the same issue.
- If you get the service started and then try to manage the user profile service application and get some silly error pop up you just need to do an IISRESET.
A couple of MSDN forum posts and other stuff that I looked at along the way:
- Post 1
- Post 2
- Blog post
- Blog post from Twitter
- If you are getting goofy DCOM issues check out this blog post for getting rid of them.
- There are two Forefront Identity Manager (FIM) services that get installed as Windows services by SharePoint. If you are troubleshooting profile imports and see FIM errors they are related to your problem. Don't try to manipulate these services manually.
- If you have a multi-server farm you only need to start the service on the server you want it running on, not all of them.
- (Added 10/18/2010) You can manually launch the ForeFront client by C:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\UIShell\miisclient.exe.
The quick steps
- Make sure your farm account has all those super permissions, domain admin might be easiest ;)
- If you had to update your farm account permissions reboot now and save yourself the headache
- Start the User Profile synchronization service, yes it will take 5 to 10 minutes to start the service
- Do an iisreset
- Go to manage your user profile service application
- Click on Configure Synchronization Connections
- Create a new connection to your domain
- Fill in all the info and then select what OUs you want to import and click OK
- From the manage profile service screen click on Start Profile Synchronization
- Cross your fingers and be patient. It takes a while
So hopefully my cheat sheet of issues helps you on your quest. I promise to make updates to this cheat sheet as I find them. Heck, I am guessing as soon as Todd gets back from lunch he will remind me of something else we had to figure out. If you run into something you think should be added leave it in the comments. I will try to work those back up into the main blog post and give you the fame and glory you deserve.
Shane – SharePoint Consulting