The SharePoint Farmer's Almanac

View my install SharePoint 2013 Webinar

Shane — Mon, 17 Dec 2012 13:47:49 GMT

My Christmas gift to you!

I don't know why I didn't do this years ago. I guess you can thank the fine folks at Rackspace for this. Today I did a 1.5 hour webinar on installing and configuring SharePoint 2013. And in a totally unexpected twist not only did everything work but I actually got everything done in the allotted time. You know what is even more exciting? I recorded the whole thing and the recording is available for you to watch. The link to the webinar is at this webinar link. Sorry you will have to register to watch just because that is how the tool works.

There is also a presentation I used during the webinar with some screenshots, PowerShell, and other links. You can find that presentation at this link.

The team is actually doing a bunch of these this week. You can sign up or watch the recordings by using the links found here.

Hope you enjoy the show. Happy holidays!

Shane

SharePoint 2013 is coming, SharePoint 2013 is coming

Shane — Tue, 02 Oct 2012 07:57:46 GMT

Thankfully, unlike the night of Paul Revere's fateful ride we are happy to see it coming. Side note: If you are bored go read this article talking about Israel Bissell who did the hard work. He managed to ride 345 miles to Paul's 12. Unfortunately Bissell doesn't rhyme as well as Revere. J Ok, enough history back to SharePoint.

SharePoint 2013 is exciting with lots of new features. Two of the biggest will be more social capabilities and the App store. The inspiration for social feature are pretty clear, it is like a hybrid of Twitter and Facebook. That's a really good thing as we move closer to the social enterprise. The App store just makes sense. Everyone these days has more Apps than they can even imagine at their fingertips on their smart phones, it was only logical that other software would start having the same capabilities. These two features are just scratching the surface of SharePoint 2013. Fortunately, if you are interested, Microsoft has some great reading on what is new and the Rackspace team has provided 9 free videos showing off some of the 2013 coolness. This article isn't about what is new.

The thing I want to focus on, the information that is hardest to find, is what you can be doing today to get ready for when the final version of SharePoint 2013 is released. The easy answer is nothing. If you are actively caring for and feeding SharePoint then you have nothing to worry about. On the other hand, if you haven't been showing your SharePoint farm all the love and attention it deserves don't feel too bad, about 95% of farms are in the same situation. If you are a little behind, let's talk a little about your "fall cleaning" plans.

Patching

Where are you with patching your current SharePoint 2010 farm? You don't know do you? That isn't a good sign. Luckily Todd has a great post that helps you find your build number and then tells you what that number means. Now, when you look at Todd's list you don't necessarily need to be on the latest and greatest; technically as long as you are at RTM then upgrading to 2013 is supported. Let's be honest though, you shouldn't be running RTM. You should be at service pack 1(SP1) at a minimum. There are 100's of fixes between RTM and SP1 so if you are not there then get a plan together to get there. What about all of those cumulative updates (CU) after SP1? Good question. As a rule of thumb you shouldn't apply a CU unless you have a specific problem and you can point to the CU that fixes it. CUs are not tested like service packs and can introduce a lot of risk. With that in mind be sure to read Todd's note on each Cumulative Update carefully to get an idea of what features they may fix or add. Another important point to remember, there is no way to uninstall a SharePoint CU or SP once you start installing it, so practice on a test farm first and then plan for the worst.

Purging

When was the last time you deleted old content out of SharePoint? No, not your field guide to the battle of Lexington and Concord, but all of those SharePoint sites that nobody uses. There have been studies that show up to 50% of collaboration sites that get created are never used. Even if you are 50% better than the average company, did you delete the 25% that aren't in use? Probably not. This is a great way to get ready for your upgrade. Everything about less content is a win when it comes to doing an upgrade. Nothing is worse than troubleshooting upgrade errors for content that you just end up deleting.

Preparing

Since SharePoint 2013 isn't RTM yet hardware specifics are still a little up in the air, but it is still obvious there will be changes. For example, are you using the Office Web Applications in SharePoint 2010? In 2010 Office Web Apps are required to be installed on a SharePoint server. In 2013 it is required that they not be installed on a SharePoint server. With that one change you have already added at least one server to your farm. What about the operating system and SQL? Windows Server 2008 (not R2) and SQL 2005 or 2008 were supported. Not with SharePoint 2013. Digging into the hardware and software requirements document provided by Microsoft will give you the information you will need to start planning you infrastructure to support SharePoint.

There is a lot more you could do to get prepared, but let's not get carried away. Your server room has smoke detectors, so one lantern by land or two by water might be overkill. If you can get through patching, purging, and preparing then you should be in good shape.

Shane Young – Rackspace Hosting

A simple install of SQL Server 2012 for SharePoint Server 2013 or 2010

Shane — Mon, 17 Sep 2012 10:51:00 GMT

One of the things that comes up in my SharePoint Administrator classes a lot is people who are looking for an easy guide to just get SQL Server up and running so they can deploy SharePoint. They aren't looking for best practices or optimal configurations just cut-to-the-chase, what they should do, instructions. So in this blog post I have attempted to provide that. If you are an old pro at SQL installs (meaning you have done it more than twice) this post isn't for you. If you are new to it all then read on.

These instructions were written using Windows 2008 R2 but I did use them on a Windows 2012 VM and the steps were the same except I did not have to install the .NET piece.

There are three things you need to get a SQL Server ready. Install, configure max degrees of parallelism, and setup your SQL permissions.

Installing SQL Server 2012 for SharePoint

Run setup.exe
From the SQL Server Installation Center click on Installation on the left hand side of the page.
On the right hand side of the page click on New SQL Server stand-alone or add features to an existing installation.
After the Setup Support Rules run, click OK.
Enter your appropriate Product Key and then click Next.
Select I accept the license terms.
Select Send feature usage data to Microsoft....
Click Next.
When the Setup Support Rules screen pops up review any errors or warnings you get. If nothing bad has happened the Next button will be available to click. Click Next.
For Setup Role select SQL Server Feature Installation and click Next.
On the Feature Selection screen this is where you need to be smart. In order to make SharePoint run you only need to select one check box, Database Engine Services. I would highly recommend you also check Management Tools - Basic and Management Tools - Complete.

Now when you read all of these awesome features you might be thinking "I want to kick the tires of Reporting Services - SharePoint" or some other random feature. That is great, tire kicking is fun and important but if you are reading the blog post to get SQL Server installed correctly for SharePoint then you probably aren't ready to start randomly installing features. Even if you were ready to install them you would still most likely come back and do them after SharePoint was up and running, not before. So let's ignore them for now and click Next.
On the Installation Rules screen SQL will make some checks. In this case my Server did not have the Microsoft .NET Features installed. You will need to manually add the feature now. While you do go ahead and leave this SQL window open.
To add the .NET Windows Server feature click on Start > All Programs > Administrative Tools > Server Manager.
1. From the right side of the screen click on Features.
2. Over on the left side of the screen click on Add Features.
3. Check the box for .NET Framework 3.5.1 Features.
4. When you check the box a window for Add Features Wizard will appear telling you the additional required roles. Click Add Required Role Services.
5. Click Next.
6. At the Web Server (IIS) screen click Next.
7. Accept all of the defaults and click Next.
8. At the Confirm Installation Selections click Install.
9. At the Installation Results screen make sure everything was successful and then click Close.
10. Jump back over to your SQL Installation Rules screen and click the Re-run button.
If the tests are Passed click Next to continue.
Assuming this is the only install of SQL Server on this server then you are going to want to take all of the default settings for the Instance Configuration screen. If you have other SQL Instances installed on this server you are more advanced than reading this blog post. J Click Next.
At the Disk Space Requirements screen click Next.
For the Server Configuration screen it is asking you what accounts you want to run SQL Server as. The only service you are worried about right now is the SQL Server Database Engine. This service should always be run as a domain account not a local account. Next to SQL Server Database engine click on NT Service\MSSQLSERVER and a drop down arrow will appear.
Click <<Browse…>>.
Select your SQL Service account and click OK.
Enter the account password and click Next.
On the Database Engine Configuration screen there are lots of changes you could make and over time you will learn about these options but for the purpose this guide you will except all of the defaults. You only need to click Add Current User before you continue on.

If you were building a production capable SQL Server best practice 101 would be to store your data and log files on different volumes. By default SQL Server will store everything on the C: drive. If you want change that behavior take a gander at the Data Directories tab.
Once you are ready click Next.
For the Error Reporting screen select Send Windows and SQL Server Error Reports...
Click Next.
At the Installation Configuration Rules screen click Next.
You are Ready To Install, so click Install.
When the installation finishes you may be prompted to restart. This is not directly because of SQL Server but instead because of other recent installs you have done that you haven't rebooted since. In my case because I added the .NET feature. When SQL is all done click Close. If you have any other open windows at this point you can close them as well. You are all done.
If you got the pop up screen to do a reboot it will not automatically happen, you will need to Reboot on your own.

Max Degree of Parallelism

Now that you have SQL Server all installed there is one more configuration change you need to do in order to make SharePoint happy. You need to change the max degree of parallelism. Don't ask me what that is. Something about number of processors and how SQL uses them. Unfortunately SQL Server defaults to 0 and SharePoint 2013 necessitates, demands, forces, requires, and otherwise really wants you to set it to 1. So make the change. If you are running SharePoint 2010 this change is not required but is recommended.

Now if you look at the link I gave you saw a bunch of fancy SQL to change it. Barf! Let's change it the easy way, with a mouse.

From your newly installed SQL Server click Start > All Programs > Microsoft SQL Server 2012 > SQL Server Management 2012.
On the Connect to Server screen click Connect. If for some reason the Server name: field is blank you would just type in the name of the server.
At the top of the Object Explorer window you see your server. Right click on it.
From the menu that appears click Properties.
In the Select a page section click Advanced.
Scroll to the bottom and change Max Degree of Parallelism from 0 to 1.
Click OK.

That does it. No need to reboot or anything else to make the change take effect.

SQL Permissions

One more quick change since we already have SQL Server Management Studio running. You need to give the Windows Account that you plan to install and configure SharePoint with some elevated rights in SQL. Typically we recommend you use a dedicated account (I like the name sp_install) and this account will need the following roles on the SQL Server.

DB_Creator
Security_Admin
Public

Make sure you still have SQL Server 2012 Management Studio open on your SQL Server.
From Object Explorer expand out Security.
Under Security expand out Logins.
Right click on Logins.
From the menu choose New Login….
For Login name: enter domain\sp_install or whatever account you will be logged into SharePoint as when you do the install.
On the left, under select a page click Server Roles.
Check the box for dbcreator and securityadmin. Also, leave public selected.
Click OK.

Hooray! Now you have your whole SQL Server ready to rock and roll so you can install SharePoint.

Why haven’t you patched your SharePoint farm?

Shane — Fri, 08 Jun 2012 08:51:34 GMT

AHHH! It seems a week doesn't go by that I don't find some ancient SharePoint farm lying around. Just recently I found such an environment that one of our customers was using. I swear this last one was used by the ancient Egyptians and was using the Hieroglyphs language pack. As of May 29, 2012 that farm is running SharePoint Server 2007 RTM. RTM? Yes, you know the thing that came out on November 11, 2006. That was 2,026 days ago! Can you imagine not patching your server for over 2,000 days? That is just crazy! Oh, and in case you were wondering, this was one of their production farms. (And don't get me started on the insanity of having multiple production farms without really good reasons, which they didn't have.)

Why do I care so much? Because I am a caring kind of guy. Ok, maybe not. Really, it's more because they are doing two things that make me a sad panda. One is giving SharePoint a bad name. I don't know the exact number but let's just say there have been hundreds of fixes, several performance enhancements, and more than handful of new pieces of functionality introduced in those 2,000-plus days since SharePoint 2007 was first released. And those patches, performance enhancements, and new functionality generally help alleviate many of the pain points some users may be having with SharePoint. If the users of that farm were complaining about something not working right, chances are that issue could have been addressed by simply applying updates to the farm. And, they could get all of that for exactly the price of free. Ok, I realize "free" isn't completely true because patching does have an associated cost but, whatever that cost is for you it is far outweighed by the cost of not patching. I will not dive into the nerdy details on this topic but remember you should always test your patches on your TEST FARM before you install them on your production farm. J

The second downside of not keeping up with your patches, and what aggravated me the most about this customer, is there is often a minimum build that a farm needs to be at in order to upgrade to the next version of SharePoint. This customer is on SharePoint 2007 RTM and they want me to move them to SharePoint 2010 (hopefully not RTM). The only problem? SharePoint 2007 has to be at Service Pack 2 or later before you can even attempt to do an upgrade! Then I ask the customer what it will take to do an upgrade and they send me over a nine slide PowerPoint that I will need to work through to help me submit the upgrade proposal to their IT governance group. It will take me probably four hours of my life just to go through the first round of justification to put this patch on, and this is even before getting to the actual upgrade to SharePoint 2010. WHY? You can give me your song and dance about controls and such but this is just ludicrous. I have written a lot of governance plans for SharePoint and I have never included a section on requiring a sacrifice to deploy a two year old patch that is pretty much mandatory. Heck, I'll even point out that right now they are not even supported. Support for the RTM version of SharePoint 2007 stopped January 13, 2009 if I can read the Product Lifecycle correctly.

If you are still on SharePoint 2007 and want to check where you are with patches you can use this link. For SharePoint 2010 use this one.

So in the future, please do yourselves, your users, and even me a favor by keeping your SharePoint farm up to date with the latest patches. You'll be happy you did, and I will too!

Shane

Health Check - Happy New Year to you and your SharePoint servers!

Shane — Tue, 03 Jan 2012 13:40:20 GMT

Happy New Year. Hopefully you have recovered from all of the good times and/or you got some rest on the break.

I figured many of us have SharePoint 2010 deployments at this point that are mature. Which is awesome. But one thing I know about mature SharePoint farms is we often take them for granted. Below I am going to throw a couple of things at you to double check this week and make sure SharePoint is happy.

What is your build number?

You should be running at least service pack 1 at this point. Now if you are not I am not recommending blindly installing it on your production server. You should test it first. J But once you do let's get it on there. How do you check your build number? Todd has a great blog post here that will show you how to find your build number and then tell you what it means. He also has links to the different patches for download. Remember service packs are always good cumulative updates… you should only install them if you have a very specific reason and you have tested.

Check those health rules

We have all gotten used to the big read bar at the top of the page in Central Administration. We know that it is generally there because some of the rules can just never be made happy. But when was the last time you checked to see what problems it was reporting? Especially with some of the updates the rules have gotten better. So take a quick peek at the list today and see if there is anything you can remedy. No reason to have a broken farm.

Check your disk space

What the heck. I know when I was a full time systems guy I had scripts that checked drive space daily and reported back to me. But maybe you don't. Either way RDP into all of those servers and just make sure some rogue log or temp files aren't wasting a bunch of space. It will take you 5 minutes per server and might very well save you from having a bad day in the future.

How is SQL Server doing?

Whether you manage your SQL Server or you have a DBA who does it you need to ask the questions. This isn't a perfect list but off the top of my head I would ask:

How much free space do we have on the data drive? The log drive? The backup drives?
How long is that space going to last us at current growth rates?
When was the last time someone confirmed we can restore from the SQL backups?
Does SQL need any patches applied for general SQL Server health?
Anybody checked the SQL logs for errors?

Remember even though it is easy to say that isn't your job it is. If SQL Server isn't happy then SharePoint isn't happy.

What is your backup/restore plan?

I know you have one in theory but do you have one in actuality? When was the last time you did a practice restore? I will leave at this. You know if you have a bad feeling in your stomach right now or not.

Clearly this isn't an exhaustive list but you get the idea. Spend this slow week making sure that awesome server farm you built is still awesome. Next week you will start getting busy and will go back into firefighting mode. Don't make your next SharePoint touch point require a 4 alarm fire.

Shane

SharePoint Consulting

SharePoint Admin class in Orlando

Shane — Mon, 28 Nov 2011 09:56:36 GMT

I sat down to write a blog post but then my VM client decided it wanted to install updates and all of that chaos so I got distracted. Now I am out of time to write a helpful blog post. So instead I will put a quick post here to remind you that I am teaching my SharePoint 2010 admin class in warm Orlando, Florida the week of December 12^th. I don't know about you but Cincinnati (where I live) is very cold that time of year so I am looking forward to a company sponsored get away. Why don't you come join me?

Shane

SharePoint Consulting

Free Turkey Today!

Shane — Wed, 23 Nov 2011 08:58:00 GMT

Update: I am an idiot. Here is the link to sign up. https://www1.gotomeeting.com/register/920583097

Unfortunately it isn't the kind you eat it is just more of Shane and Todd's cheeky shenanigans. In the spirit of Thanksgiving, two of SharePoint's biggest Turkeys are putting on a free webinar from 3 to 4 PM EST today 11/23/2011. The session will be completely informal where anyone can post SharePoint questions and they will give it their all to answer them. Cranberry sauce not included.

Fine print:

The meeting only holds 100 people so first come, first served.
When you register the email will come from Citrix. It is very common for it to get caught in junk/spam filters.
The session will be recorded but the recording will more than likely not be available after the fact.
Be sure to wear your comfy/stretchy pants so you don't get too stuffed.

We all know you aren't doing any real work today anyway so you might as well jump into the part.

Shane

SharePoint Consulting

PS – Why aren't you signed up for my admin class in Florida in December? You got somewhere better to be.

Find me at SharePoint Conference

Shane — Fri, 30 Sep 2011 12:29:13 GMT

Hopefully your bags are packed and you are ready to head to the Anaheim for the sold out SharePoint Conference next week. I know I am excited. Quickly I wanted to give you a list of my sessions and other events where you can stop by to say hello or heckle (whichever you prefer) next week.

Sessions:

All three sessions will be a good old time. My partner in crime Todd Klindt and I will do our best to entertain and hopefully teach you something along the way.

Understanding SharePoint Administration Part 1 Monday 11 AM Marriott: Platinum Ballroom 1-5
Understanding SharePoint Administration Part 2 Monday 3:45 PM Marriott: Platinum Ballroom 1-5
Planning and Implementing SharePoint 2010 Upgrade and Migration Tuesday 3:15 PM Marriott: Platinum Ballroom 1-5

Post Conference:

No Todd just me but it is a special all day deep dive into SharePoint 2010 administration on Friday. Should be lots of fun. I plan to beat as much knowledge into your heads as possible. The post conference is an additional registration. For more info check out http://www.mssharepointconference.com/Pages/pre-post-conference-trainingpage.aspx#5

Free Books:

Who doesn't love free books. Todd, Steve, and I will be signing our SharePoint 2010 admin book at a few different places during the week.

Monday between 6:30 and 8:30pm we will be at the ESPN Zone at the Idera party signing books.
Wednesday at 3 PM we will be at the Rackspace booth. They bought a lot so come get one.
Wednesday evening during the Reception in the Exhibit hall we will be signing a few more books at the Rackspace booth.

Random events:

Tuesday from 12 to 12:30 Todd and I will be at the Quest booth doing some crazy thing. Some game show. Should be fun and requires audience participation.

At the booth:

SharePoint911 will have a booth as always. Come say hello. We have a whole bunch of fun people to meet there. For more info or pretty pictures of the team click here.

Randy Drisgill - MVP
Phil Jirsa
Todd Klindt - MVP
Jennifer Mason
Jonathan Mast
Raymond Mitchell
Larry Riemann
Laura Rogers - MVP
John Ross - MVP
Nicola Young
Shane Young – MVP

Even more important? At the booth we will be giving away stress reliever Cows, and two new mystery animals. J Very exciting. Be sure to Moo at anyone in the booth to get the mystery animals.

See ya there!

Shane – SharePoint Consulting

After SharePoint 2010 database attach upgrade alerts have the wrong URLs

Shane — Mon, 22 Aug 2011 13:47:21 GMT

Database attach upgrades seem to be the norm these days for customers upgrade from SharePoint 2007 to SharePoint 2010. I am assuming the reason for this is because they are very flexible and generally work pretty well. One of the flexible things about these type of upgrades is you can change your web application URL. Some customers are going from short URL to fully qualified (FQDN) like http://portal to http://portal.company.com. And some of our customers are making complete changes going from http://sharepoint.company.com to http://intranet.company.com. The nice thing about making these types of changes is for the most part a content database has no concept of the web application URL. If you go hunting through the database (which you should never do) you will see everything is relative. The site collections know their urls as / or /sites/sitecollection. That way changing the URL doesn't matter.

But then there are alerts. Alerts are hard coded to the web application URL that was used to create the alert. This is why if you have multiple URLs for you SharePoint site your alerts may be inconsistent. If your portal is setup so you can access it as http://portal or http://portal.contoso.com then whichever of those URLs you are browsing the site with when you click create alert will be the URL SharePoint sends out in the alerts. Kind of annoying for some people but it is what it is. The real problem comes if you switch URLs.

If you change your web applications URL (maybe during an upgrade but not necessarily) everything will continue to work great except for existing alerts. When you have an alert sent to you it will still have that original URL you used to create the alert even if that is no longer a valid URL. Boo!

Now if you do a Bing search of the internet you will find lots of people point to this TechNet resource http://technet.microsoft.com/en-us/library/cc508847.aspx which will prompt you to create a Windows PowerShell script to fix alerts. One small problem. The script only works to update the URL of alerts for the root site collection. In their script they confuse the web application URL and the site collection URL. To be fair I don't blame them. When you look at the configuration objects you will see it wants siteUrl and we have been taught that usually inside of SharePoint site = site collection. Unfortunately in this case siteUrl actual means web application URL.

In the beginning when we used their script to update http://portal/sites/old to http://portal/sites/new our alerts had the link as http://portal/sites/new/sites/new/list which has /sites/new twice.

So then I decided to look at things on my own. I created a new alert through the GUI and then used the following script:

Get-SPweb -site http://portal/sites/new -limit all | ForEach-Object {$_.alerts|foreach-object{write-host $_.user $_.properties["siteUrl"] $_.properties["dispformurl"]}}

This gave me a list of all the alerts for the site collection http://portal/sites/new and I saw the value for siteUrl was http://portal. Hooray!

So then I used this script to update just the alerts in that site collection:

Get-SPweb -site http://portal/sites/new -limit all |ForEach-Object {$_.alerts|foreach-object{$_.properties["siteUrl"] = "http://portal/sites/new";$_.update()}}

Success! But seemed silly to just fix the one site collection so then I wrote a better script that updates the entire web application:

get-spsite -limit all -WebApplication http://portal | get-spweb -limit all |ForEach-Object {$_.alerts|foreach-object{$_.properties["siteUrl"] = "http://portal";$_.update()}}

Now if you compare my script to theirs you will notice I don't bother with mobileUrl because no one I know uses it. Also, they rewrite some other properties. If you want to do the same you can piece together the two scripts to do it but for right now for my customers this is working.

Hope this helps

Shane

SharePoint Consulting and now SharePoint Training

Using PowerShell to export all solutions from your SharePoint 2010 farm and other fun

Shane — Wed, 04 May 2011 21:43:18 GMT

Yesterday my client presented a fun little challenge. They have one 2010 production farm they have been using for the last couple of months. On it they have about 25 WSPs that their developers have created. (Insert funny developer joke here. Probably something about a 1000 developers, a keyboard, and creating a Shakespeare novel.) They wanted to move to a new 2010 farm and they also wanted to provision an integration (aka QA or UAT) farm. When I asked for the WSPs they gave me a pile but they were not sure if those were the actual ones deployed in production. Ugh. So instead we decided to figure out if we could extract the actual WSPs from the running farm. Turns out you can, you just need to use my friend Windows PowerShell. J

After a little playing we came up with this to extract them all from the farm.

Extract all of the Solutions from your farm

(Get-SPFarm).Solutions | ForEach-Object{$var = (Get-Location).Path + "\" + $_.Name; $_.SolutionFile.SaveAs($var)}

Quickly let's see if we can break this down and explain the pieces.

Get-SPFarm does just that it gets your current farm. When I put it in the ( ) that returns the farm. Then I tack on .Solutions which returns all of the solutions in the farm. From there I pipe the solutions over to old faithful ForEach-Object. ForEach-Object says do everything within the { } to each solution passed from the pipe. Within the { } I use $var = to set the variable's value to Get-Location which returns the current location you are at in the file system. .Path returns that location. (Example output: c:\backupfolder) The + says continue to add to the $var variable. "\" adds a \ to the $var variable. Another + means keep adding to the variable. $_.Name says give me the name property of the current solution. So this ends up setting the value of $var to c:\backupfolder\mysolution.wsp assuming the solution filename was mysolution.wsp and we were running our PowerShell from the folder c:\backupfolder. Finally we have a ; which means we are all done with that line.

We follow up setting the variable with $_.SolutionFile.SaveAs($var). $_.SolutionFile is a property of the current solution. .SaveAs is a method for saving that file. That method needs to know what filename to save the solution to. We give it $var which is the variable we just created.

Boom! Just like that you have exported all of the solutions from your farm to a handy, dandy folder.

Import all of the Solution into another farm

Now because I am naturally lazy I said "I bet we can figure out how to script importing all of those to our farm." After a little playing turns out you can with the following PowerShell.

Get-ChildItem | ForEach-Object{Add-SPSolution -LiteralPath $_.Fullname}

So how does that work? Get-ChildItem returns all of the files in a folder so if you navigate to the folder you copied over all of the solutions to you return them all. For this example we will say we are in the folder c:\copiedfolder. We then pipe those files over to ForEach-Object so we can do everything within the { } to each object. Add-SPSolution is a SharePoint cmdlet for adding solutions to a farm. –LiteralPath is a required parameter where you need to provide the path to the solution to import. $_.Fullname returns the .fullname property of the object. So in this case it returns c:\copiedfolder\mysolution.wsp.

Oh yeah! Just like that all 25 of those solutions are added to our farm.

Deploy all of those Solutions

So we got this far without me having to type in a bunch of crap so surely we can automate this part also. <he he he> (Keep in mind when I explain the developer crap below it might not be 100% perfect but you get the idea.)

Get-SPSolution | ForEach-Object {If ($_.ContainsWebApplicationResource -eq $False) {Install-SPSolution -Identity $_ -GACDeployment} else {Install-SPSolution -Identity $_ -AllWebApplications -GACDeployment}}

Get-SPSolution is pretty easy that returns all of the solutions in the farm. As a side note there are a lot of properties you can play with here. So you could for example find out which ones are already deployed, in our case we didn't have any solutions so we didn't mess with it. ForEach-Object is going to run all of the cmdlets within the { } on each solution. The If cmdlet allows us to evaluate the contents of ( ) if it is true we do the next set of { } if it is false then it will process the { } after the else statement. $_.ContainsWebApplicationResoruces is a true or false property of a solution. –eq checks if the property is equal to $False. $False is a PowerShell system variable that represents false. So this statement checks to see if the solution has web application resources because if it does we need to install the solution a different way. For the solutions that don't have web resources ($false) we run {Install-SPSolution -Identity $_ -GACDeployment} which is the SharePoint PowerShell cmdlet for deploying a global solution. For the solutions that do have web application resources we run {Install-SPSolution -Identity $_ -AllWebApplications -GACDeployment} which just tells SharePoint to deploy those resources to all of the web applications in our farm. I am guessing you don't necessarily have to deploy them all to the GAC (-GACDeployment) but this is the way my customer wanted it so I said ok.

When you run the command you should just be returned to the prompt. You can then go to Central Admin > System Settings > Manage farm solutions. Here you will see your solutions and their current status. If you deploy a lot at once it can take 10 minutes or more for them all to go from deploying to deployed but they will. Just be patient.

Hopefully now you feel equipped to go play. Remember the idea here is for you to learn about the moving pieces. Yes my scripts work as is but I am guessing you can take these and massage them to be much cooler. I am just a PowerShell hack who figures out the first solution that works instead of always figuring out how I can refine it to the most efficient, coolest thing ever. J Though I do think I had it worked out to do the import and deploy in one string of commands but we had to return to real work before we finished that part.

Thanks to Todd for double checking me and making the random edits because I suck at English. And thank you to Jeff Jacobs. He was the customer that helped me pound my way through this fun stuff and laid out the challenge.

Shane – SharePoint Consulting

PowerShell doesn’t show all of your SharePoint 2010 content databases

Shane — Wed, 27 Apr 2011 22:05:00 GMT

Today SharePoint managed to freak me out for a few minutes. I was looking at a customer's farm and when I ran the PowerShell cmdlet Get-SPContentDatabase it was only returning one content databases even though my farm has two content databases. The output looked like this.

So then I thought about it and figured I had the problem where the account I was logged in as didn't have access to the other databases. So then I grabbed Todd's blog post on How to create a SharePoint 2010 admin account and stop using sp_farm because I knew it would jog my memory on how to give my account access to the databases. I ran through it and I still got just the two databases. UGH.

So then I figured when all else fails try Central Admin. When I went in to manage content database sure enough they were all there. But then that is when I saw a clue. The content database I couldn't see was "Stopped".

Surely that isn't the issue? But I try anyway. I quickly set the database back to started and then run my PowerShell again.

That fixed it. Well, I guess you learn something new every day. The more we play with it the more it seems to be a lot of little things that happen when you leave a database in the stopped/offline state. I think as a rule of thumb leaving databases in this state is a bad idea. Some of the weirdness we have seen is with timer jobs, like the profile sync job, don't run against those databases.

Why do people leave databases in the stopped state?

The main reason people do this is because they do not want any additional site collections to be created in that content database. And that is admirable goal if you are trying to control database sizes. The key is the better way to accomplish this is to set the maximum number of site collections to the current number of site collections. Same result without weird behavior like this.

Another way to see all of the content databases regardless of state

This comes from one of my developers named Jonathan Mast. He suggested instead of using Get-SPContentDatabase that I use Get-SPWebApplication | ForEach {$_.ContentDatabases} | Select Name to get all databases regardless of state. That works pretty well.

Todd would like you to know

If you use Get-SPDatabase | Select Name, Status SharePoint will give you a wonderful list of all of your SharePoint databases (config, services, and content) and show you their status. In this case my mystery database would have shown as Disabled. Another nice trick when fighting through a problem like this.

Hope this helps

Shane – SharePoint Consulting

A new SharePoint training company

Shane — Thu, 27 Jan 2011 10:05:11 GMT

Who could it possibly be? It's SharePoint911, of course! I can hear it now: "But don't you guys already do training?" Actually, the majority of our team has done SharePoint training for years, but for the most part we have we have done it under the umbrella of other training companies. We have written at least 10 different classes for these different companies, and we have taught 1000s of students over the years, but always for someone else.

For the first time ever, we are creating our own training content and we have 100% control. No more creating modules to fit a specific format or marketing objective. After talking to a customer who got an early preview of the outlines, his exact quote was:

"I love the content. When you read the training page you can feel the passion you guys have for SharePoint and you get a good sense of the high level of experience." -Andrew Post, MCSE, MCP

That is exactly what I wanted to hear! These classes are written and taught from the heart.

And because I believe you should always lead with your very best, the first-in person SharePoint 2010 administration class will be designed, written, and taught by Todd Klindt and yours truly. Go read the outline. It isn't marketing speak or hot air; it is all of the stuff that Todd and I are dying to talk about. We also created the outline in the opposite order of most - we wrote down everything we wanted to cover, and then cut it down to make it fit neatly in five days, and put it in a logical order. Through dumb luck we ended up with 15 modules.

The first teaching of the class will be in Cincinnati, Ohio from April 4 - 8, 2011. And because it will be the first class, we are offering a $500 discount. So instead of the normal price of $2,999 you will only pay $2,499. How can you pass up a deal like that?

If that weren't enough, we are also offering online classes. These will be live, 75-minute sessions taught by subject matter experts from our team. These are taught in the same style as we use for our internal training. That means no "death by PowerPoint." Instead, you'll get hard, fast information that you can take action on right away. Heck, I think one of the classes doesn't even have slides, but instead will be 100% demo on building a solution. Awesome. You can find a complete list of everything about our training and the upcoming classes here.

That is enough to get us started, but don't worry. The training division of Sharepoint911 is going to grow very rapidly. We have several ideas for upcoming classes that no one else is offering to make you the biggest and badest SharePoint Ninja on the block.

Thanks

Shane

SharePoint Consulting & now SharePoint Training

Search Database GUID issue

Shane — Mon, 06 Dec 2010 10:20:24 GMT

So in the quest to have no GUIDs I wrote the blog post How to remove the GUIDs from the SharePoint search service application databases to great fan fair. After reviewing my VM and other servers I have performed the steps on I have found the error message below. (Text and image included to help with the search engines getting you here.)

SQL Database 'NewSearch_DB_e28b777e4e664c479879f5a257b932f9' on SQL Server instance 'CowTown' not found. Additional error information from SQL Server is included below.

Cannot open database "NewSearch_DB_e28b777e4e664c479879f5a257b932f9" requested by the login. The login failed.

(Don't make fun of my server being named CowTown.)

So that seemed kind of scary but made sense because I had deleted that old database. After digging around I found that search seemed to work fine and apparently one of the timer jobs was just trying to check this database once an hour. So first thought I had was "I wonder if SharePoint still thinks that is a database somewhere even though the Search service application isn't using it?"

Well, I know PowerShell to find out the answer to that question. I opened up a SharePoint Management Shell and simply ran:

Get-spdatabase

Which gave me the output below:

Sure enough. The old database is still listed even though Search isn't using it. UGH. (Fifth database from the bottom.)

Another place I saw it that was kind of freaky was Central Administration > Upgrade and Migration > Review database status

Here you can see that it is listed as Not Responding. UGH.

So all of this makes sense. We did delete the database because Search doesn't use it anymore. Now we just need a way to tell the farm to quit trying to reference it. I fought with about 3 different ways to make this work and finally I came up with this one which I believe should be completely supported. J (My other ways may have been a little too direct.)

Getting rid of the error

Open the SharePoint Management Shell
Type get-spdatabase and press enter. This will give the output below.
Find the database in question. You need to then copy the Id for it. You can right click in PowerShell and choose mark.
Type $bad = get-spdatabase <your id> and press enter.
Type $bad and hit enter. This will show you the database you have in the variable. It is your last chance to double check you got the correct database.
Type $bad.Delete() and press enter. No more database.
Type get-spdatabase and press enter. All better.

At this point all of your worries are gone. No more stupid error message. Standard precautions try this in your test world first. You are up a river without a paddle if you do this for the wrong database since it is a pretty violent way to delete the database.

May the force be with you!

Shane

SharePoint Consulting

Rename the SharePoint 2010 PerformancePoint database to remove the GUID

Shane — Thu, 04 Nov 2010 12:47:15 GMT

When I build a farm with the intention of not having any GUIDs I use the Central Administration page Manage Service Applications to create most of my service applications. And for most of the service application that have databases the GUI gives me the chance to name the database, which means I can avoid having those gosh darns GUIDs. There are two service apps that don't play nice with this strategy Search and PerformancePoint Services (PPS). I covered how to do the Search rename so now it is time to get rid of the PPS database GUID.

Thankfully this is pretty straightforward.

First I went into Central Admin > Manage Service Applications and clicked New > PerformancePoint Service Application. I named it Blog PerformancePoint Service App

If I jump over to SQL I now have the highlighted database

Completely unacceptable.

So now what?

Rename the PPS database

Go to SQL Management Studio and rename the database
1. Open SQL Management Studio. You may have to go to your SQL Server to do this.
2. Attach to the instance that host SharePoint
3. Find your database
4. Right click on the database name and choose Rename
5. Delete the GUID off the end of the name or make the name whatever you want then press Enter. SQL Database is now renamed. Notice I changed all of the spaces to underscores. Why? Because DBAs hate spaces in names more than they hate GUIDs and I am a nice guy.
Now go to your SharePoint Server and use PowerShell to set the database name.
1. Click Start > All Programs > Microsoft SharePoint 2010 Products > SharePoint 2010 Management Shell. If you have UAC enabled be sure to run it as Administrator.
2. Then run the following line. Be sure to replace your info for service app and database name.

Now you can celebrate you have saved the world another GUID. I have a master post here with all of the anti GUID posts linked in one place. Right here.

Shane

SharePoint Consulting

Getting rid of GUIDs in SharePoint 2010 database names

Shane — Tue, 26 Oct 2010 15:59:00 GMT

It is like your typical battle of good vs. evil. SharePoint 2010 has a secret plot to run the world out of GUIDs and between you and me I think it has a good shot of accomplishing its goal. Well, me and boy wonder (aka Todd) have seen the pain and suffering they are trying to evoke and we have plan to stop it. Creating blog posts to remove as many of the GUIDs as possible.

"But dynamic duo who cares if the world runs out of GUIDs?" Well, to be honest the people it scares the most are the poor developers. And while we generally consider developers second class citizens that doesn't mean we wish them harm. And let's face it, if they didn't have GUIDs they would have nothing to do. And we all know bored developers will wander the halls of your office building aimlessly. Or worse they will congregate in places like the break room and will want to make small talk with you when you go to get an afternoon Mt. Dew. I don't know about you, but nothing ruins my day worse than idle chit-chat with a developer. Yucky.

So this post is your one stop shopping for everything about getting rid of the GUIDs: As Todd or I post new items for removing GUIDs we will update this post.

How to get rid of the Central Admin database GUID by Todd

How to get rid of the SharePoint 2010 Search service application database GUIDs by Shane

How to clear timer job error after renaming the Search Admin database by Shane

Microsoft article on renaming databases (Be careful, it isn't perfect yet)

How to rename the PerformancePoint Database by Shane

Build your farm without getting GUIDs in the first place by Todd

As always remember to test any of these steps on a nonproduction server before attempting on your real servers.

Save the GUID!

Shane

SharePoint Consulting

PS - I don't hate developers. Really, it just seems that way.

SharePoint 2010 database attach upgrade with managed paths

Shane — Mon, 25 Oct 2010 10:00:52 GMT

This week I found a new to me issue with doing a database attach upgrade from 2007 to 2010. It seems if your 2007 content database has additional wildcard managed paths (anything other than /sites) that when you upgrade that database to SharePoint 2010 that you will end up with a bunch of explicit managed paths in SharePoint 2010. Kind of break downs like this:

2007 Wildcard managed paths:

/sites
/departments
/projects

2007 site collections in the content database:

/
/sites/teamsite
/departments/hr
/departments/accounting
/projects/CowMachine
/projects/CowNinja

When you create a new 2010 web application and attach the content database you will get the following managed paths:

/sites - wildcard
/departments/hr - explicit
/departments/accounting - explicit
/projects/CowMachine - explicit
/projects/CowNinja - explicit

And of course all of your site collections will be available.

As you can quickly tell this is way less than ideal. For one when you try to create a new site collection for the Cow Black Ops project you will not be able to create it at /projects/BlackOpsCows because there is no longer a managed path for /projects. Boo! So how do you fix it? About time you asked.

Create managed paths before attaching 2007 content databases

The fix here is quite simple. Know your managed paths you need before you do your upgrade. Then right after you create the 2010 web application and before you do the mount-spcontentdatabase you need to go into Central Admin > Web Application management, click your web application and then from the ribbon select managed paths. Now create your wildcard manage paths. In this example you create /departments and /projects. Now return to your regularly scheduled program and do your 2007 content database upgrade.

If you already find yourself with this issue the fix is as simple as you are assuming. Go into central admin > manage content databases and remove your upgraded databases. Once they are detached go delete all of the explicit managed paths for your database. Then create the wild card paths you want. Now reattach your content database. All better. J

Hope this helps

Shane

SharePoint Consulting

BCS and SharePoint Workspaces limited to 2000 items from external list

Shane — Mon, 18 Oct 2010 20:08:00 GMT

My client and I fought these issues for about a month all said and done so I figured I would post some of the things we learned along the way to save you a month of your life. J

The BCS is limited to 2000 items

True story. Out of the box business connectivity services throttles your connection to 2000 items. Yikes. Makes sense to keep performance in check but for most of my customers this has been an immediate issue. Luckily Microsoft anticipated this and gave us some Windows PowerShell to increase the limit or even turn it off. Luckily the BCS team wrote a post on how to manipulate this and saved me the effort. http://blogs.msdn.com/b/bcs/archive/2010/02/16/bcs-powershell-introduction-and-throttle-management.aspx Thanks guys.

Workspaces only likes 2000 items also

So we got through that and then we started syncing the list with SharePoint Workspaces and were quickly greeted with:

Too many items were returned. The limit 2000 was enforced.

What the heck? We got rid of the 2000 item limit. We did some more playing around and also found out that Outlook also could not sync the list. UGH. After opening a support ticket with Microsoft and working with Patrick G. we found the answer. There is a special registry edit you can make to allow the client BCS framework to overcome the 2000 item limit. The key is:

[HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Common\Business Data\Synchronization]

Then you need to create a dword for "Query Instances Limit". Then set the value you would like. This registry change is on the client machine trying to do the sync.

Pretty cool stuff. Hopefully this saves you some time.

Shane

SharePoint Consulting

How to remove the GUIDs from the SharePoint search service application databases

Shane — Tue, 28 Sep 2010 21:48:00 GMT

Update 12/6/2010 - Found an issue after you finish these steps where you get an error in logs. The error doesn't break anything and is just annoying. To clear that error check out this post - Correcting SharePoint 2010 Search Database Error.

WARNING: This is pretty hardcore stuff and I have only tried it in a handful of environments. While the process has been successful for me that doesn't guarantee it will be successful for you. I highly recommend you try this in a dev environment before running it in production. If you are building your farm fresh that is the best time to do this. If you screw it up you can delete the search service app and try again. If you have a running a production farm already tread lightly. Also, I am pretty sure Search will be unavailable for the entire time you are doing these steps so plan accordingly. Don't be scared. This will work; you just need to play it safe.

So I don't know about you but I am on to SharePoint's game. It has a secret goal to run the world out of GUIDs. Well, being a proud citizen of the world I am here to help save unnecessarily wasted GUIDs so developers can continue to use (unnecessarily?) them for years to come. (And to think, you thought I hated developers. This is clearly for their benefit.)

My partner in crime Todd and I have been working in our secret lair on this very topic. And while we are not completely ready to share all of our findings I am proud to publish one of the first pieces. How to get rid of the GUIDs in the Search database names. There is an article on TechNet that talks about how to rename or move the service application databases but, I had a hard time following it and getting it to work so I thought I would post a little easier to follow version.

For this post I created a Search service application call Blog Search Service App using Central Administration. After it completed I was stuck with the following three databases with those unnecessary GUIDs stapled on the end.

Renaming the Crawl Store database

In Central Admin go to manage service applications
Click on your Search service application
Scroll down the page and click on modify under Search Application Topology
Under Databases click on your Crawl Database and from the drop down click Edit properties
Find the database name and simply highlight the GUID and hit delete
Click OK

When you return to the manage topology screen you will see pending update. The change will not be committed until you click the Apply Topology Changes button at the bottom of the screen. Don't do it yet though, lets rescue another GUID first.

Renaming the Property database

Assuming you are still on the same page from the last step
Under Databases click on your Property Database and from the drop down click Edit properties
Find the database name and simply highlight the GUID and hit delete
Click OK

Now all that is left is to scroll to the bottom of the page and click Apply Topology Changes. This will probably take a couple of minutes to run. So just kick back for a moment and think of what better planet you left for the children by saving these two GUIDs. It may take a while to run depending on the state of your databases. Mine took about 6 minutes on empty database for my VM.

Here is a screen shot of the results. That was really pretty painless too bad the next one is not.

Renaming the Admin database

Put on your big boy pants because this one is going to require some ninja like SQL and PowerShell skills. (Or I guess you can just cut and paste what I have here.)

On your SQL Server open SQL Server Management Studio
Find your Search admin database. From the screen shot mine was named Blog_Search_Service_App_DB_fe289c49b61344b48952a546e48e0135. Right click on it on the database and select Tasks > back up…
Back the database up. If you are unsure how to do this the defaults should work fine so click OK.
At the backup successful message click OK
Scroll up to Databases, right click and select Restore Database…
Click the radio button for From device: and the click the … button to the right.
Click Add
Now select the backup file you just created. If you just clicked OK on the backup screen SQL should open right to the file for you. Once you find it click OK.
Click OK on Specify Backup
Check the box under Restore next to your backup
Now look toward the top of the window and enter your new database name in the To database field. For the example I entered Blog_Search_Service_App_DB. Double check yourself in the screen shot below.
Click OK
At the successful screen click OK

The SQL hard work is over but don't close management studio quite yet. You will need to come back to delete the old database in a little bit.

Now go back over to your SharePoint server
Open the SharePoint Management Shell by clicking Start > All Programs > Microsoft SharePoint 2010 Products > SharePoint 2010 Management Shell
Now enter the following line of PowerShell remembering to change the identity to your service application name:

$searchapp = Get-SPEnterpriseSearchServiceApplication -identity "Blog Search Service App"
Now enter the following line of PowerShell (it might take a minute to run):

$searchapp.Pause()
Now enter the following line of PowerShell remembering to update your database name and database server:

$searchapp | Set-SPEnterpriseSearchServiceApplication -DatabaseName "Blog_Search_Service_App_DB" –DatabaseServer "2010server"
Now enter the following line of PowerShell:

$searchapp.Resume()
Double check yourself in the screenshot below.
Now before you continue you need to make sure the database change is complete. The best way to do this I believe is to use this PowerShell:

Do {write-host -NoNewline .;Sleep 10; $searchInstance = Get-SPEnterpriseSearchServiceInstance -Local} while ($searchInstance.Status -ne "Online")

This will display a . every 10 seconds until all of the search components return to an online state. It might take a few minutes but be patient.

Now jump back over to the SQL Server to delete that final database with a GUID and restore peace and order to society.

In SQL Management Studio find the database with the GUID, right click on the name, and click Delete. (If you are the nervous type backing it up first isn't the worst idea you have had today.)
Check the box at the bottom for Close existing connections and click OK.

Hooray! No more nasty GUIDs.

Shane

SharePoint Consulting

What service accounts do you need to install SharePoint 2010?

Shane — Wed, 14 Jul 2010 22:45:06 GMT

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

Configuring profile import in SharePoint 2010

Shane — Fri, 09 Jul 2010 11:10:00 GMT

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.
1. Central Admin > System Settings > Manage services on server
2. Scroll down and find the User Profile Synchronization Service and click Start
3. You will see an account listed. This is the account that must be a local administrator account
4. 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:
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
1. Make sure your farm account has all those super permissions, domain admin might be easiest ;)
2. If you had to update your farm account permissions reboot now and save yourself the headache
3. Start the User Profile synchronization service, yes it will take 5 to 10 minutes to start the service
4. Do an iisreset
5. Go to manage your user profile service application
6. Click on Configure Synchronization Connections
7. Create a new connection to your domain
8. Fill in all the info and then select what OUs you want to import and click OK
9. From the manage profile service screen click on Start Profile Synchronization
10. 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