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

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

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.

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

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()}}

<Insert happy dance here!>

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

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

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

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

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.

Login failed for user 'CONTOSO\sp_farm'.

(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

1. Open the SharePoint Management Shell
2. Type get-spdatabase and press enter. This will give the output below.

   

3. Find the database in question. You need to then copy the Id for it. You can right click in PowerShell and choose mark.
4. Type $bad = get-spdatabase <your id> and press enter.

   

5. 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.

   

6. Type $bad.Delete() and press enter. No more database.

   

7. 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

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

1. 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.

      

2. 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

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.

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

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

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

1. In Central Admin go to manage service applications
2. Click on your Search service application
3. Scroll down the page and click on modify under Search Application Topology
4. Under Databases click on your Crawl Database and from the drop down click Edit properties
5. Find the database name and simply highlight the GUID and hit delete
6. 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

1. Assuming you are still on the same page from the last step
2. Under Databases click on your Property Database and from the drop down click Edit properties
3. Find the database name and simply highlight the GUID and hit delete
4. 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.)

1. On your SQL Server open SQL Server Management Studio
2. 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…
3. Back the database up. If you are unsure how to do this the defaults should work fine so click OK.
4. At the backup successful message click OK
5. Scroll up to Databases, right click and select Restore Database…

   

6. Click the radio button for From device: and the click the … button to the right.

   

7. Click Add
8. 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.
9. Click OK on Specify Backup
10. Check the box under Restore next to your backup
11. 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.

    

12. Click OK
13. 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.

1. Now go back over to your SharePoint server
2. Open the SharePoint Management Shell by clicking Start > All Programs > Microsoft SharePoint 2010 Products > SharePoint 2010 Management Shell
3. 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"

4. Now enter the following line of PowerShell (it might take a minute to run):

   $searchapp.Pause()

5. 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"

6. Now enter the following line of PowerShell:

   $searchapp.Resume()

7. Double check yourself in the screenshot below.

   

8. 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.

1. 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.)
2. Check the box at the bottom for Close existing connections and click OK.

Hooray! No more nasty GUIDs.

<Insert witty ending here. Something of the style of Batman and Robin. Todd is Robin of course, he makes a great boy wonder in his shorty shorts. >

Shane

SharePoint Consulting

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.

1. 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.

    

2. 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.

    

3. 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.

    

4. 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.

    

5. 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.

    

6. 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.

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. A couple of MSDN forum posts and other stuff that I looked at along the way:
   1. Post 1
   2. Post 2
   3. Blog post
   4. Blog post from Twitter
7. If you are getting goofy DCOM issues check out this blog post for getting rid of them.
8. 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.
9. 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.
10. (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.
11. 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

So admittedly my blog has been very quiet for a while. That is because I have been knee deep in 2010 for longer than I care to remember. I am been creating new materials and I have even been traveling the country doing the SharePoint 2010 IT Pro Ignite tour. Five extended days of IT Pro training put on by Microsoft. Todd and I have had the privilege of both writing and teaching parts of this class along with some really great folks at Microsoft, both MCS guys and Product team. Hopefully most of that stuff will make it to TechNet one day for your learning pleasure. Until then here are some of the other materials the team at SharePoint911 has created for Microsoft to get you going.

IT Pro Reviewers guide: http://technet.microsoft.com/en-us/library/cc262881(office.14).aspx

Experiencing the Microsoft SharePoint 2010 User Interface (E-learning): http://www.microsoft.com/learning/_silverlight/learningsnacks/SP10/snack02/Default.html

Managing and Troubleshooting with Microsoft SharePoint 2010 (E-learning): http://www.microsoft.com/learning/_silverlight/learningsnacks/SP10/snack03/Default.html

Series of videos on 2010 IT Pro features by SharePoint MVPs: http://technet.microsoft.com/en-us/sharepoint/ee518660.aspx

Once you get through all of that I am sure you will be chomping at the bit for that Beta that will show up in November. Be sure to preregister for the beta here. http://sharepoint2010.microsoft.com/try-it/Pages/Trial.aspx Oh yeah, that site is running on SharePoint 2010.

And finally if you are looking for full scale 2010 training to get you on the road to being kick butt at 2010 look here. http://www.criticalpathtraining.com/Courses/Pages/SharePoint2010AdministratorsSurvivalCamp-Agenda.aspx Todd and I writing this course as we speak and it will be available for web and inperson delivery starting December 7 with a webcast and then December 14 in sunny Tampa Florida. Come join in the fun.

Shane

SharePoint Consulting

http://www.atlspug.com/default.aspx

I will be in town to teach a 2010 class and got invited to speak on some 2007 stuff. I will be doing my server auditing session. No PowerPoint just working throuh SharePoint Central admin and SQL. Fun stuff.

Hope to see you there.

Shane

SharePoint Consulting

Last week I had the privilege of speaking at the SharePoint Technology Conference in Boston. Too cool. Got to meet several new people from the Twitterverse (I am @ShanesCows in case you were wondering). I would list the people but I never know if that is appropriate or not. Anyway.

I promised a download PDF of all of the sessions I did so here they are.

Todd Klindt and I did a whole day workshop on being a SharePoint administrator. For that session I have two decks. The SharePoint Admin deck is old faithful. It is all of the core Admin stuff we have delivered around the world brought back to glory once again. Good stuff. The other deck is stolen straight from my SharePoint Administrator's Class and it all of the dev things we admins need to know, like Features, Solution Packages, and Code Access Security (EEK!). You can get that deck here. Dealing with developers is fun. ;)

The following day I had to do my search session all by myself. Very sad. You can grab that deck here.

Shane

SharePoint Consulting

Wow the weeks are getting away from me. Thought I would quickly list out some of my upcoming usergroups, webcasts, trainings, and conferences. Just so you know what to avoid. ;)

Available now from your desk:

Todd and I while at TechEd recorded a quick TechTalk – SharePoint: What could possibly go wrong? "SharePoint environments are like snowflakes. Each one is intricate and it seems no two are alike. In this TechTalk, Shane and Todd talk about some of the things done wrong in SharePoint installations they've seen. They also talk about how to fix those things." Available for a free viewing at http://www.msteched.com/online/view.aspx?tid=8d46ef7a-7455-4854-a66d-0fd692766b58

May 21, 2009 Columbus, Ohio:

I will be presenting at the Columbus Usergroup monthly meeting at 5:30 pm. This will be my second trip to hang out with this group so it should be fun. Someone has graciously offered to let me odd their server farm in front of everyone. Yikes! So I will be looking for mistakes in the install and config and giving guidance on common mistakes along the way. http://www.sharepointgroups.org/cospug/default.aspx

May 22, 2009 Columbus, Ohio:

I get to do my first keynote! The COSPUG is having a one day FREE SharePoint Show-n-tell event! http://www.sharepointgroups.org/cospug/Pages/Show-N-Tell.aspx I know this is late notice but if you can register now before spots fill up. This will be an awesome day of practical experience.

June 1, 2009 your desk:

I will be doing a virtual usergroup presentation for SharePoint Nation. http://www.facebook.com/home.php#/event.php?eid=83970739778 Will be those core admin topics making sure that deployment was done right.

June 1, 2009 – June 5, 2009 your desk:

My world famous admin webcast is running this week. With everyone having their training budgets (especially travel) being cut so hard the online class has become quite popular. Need hardcore admin training you have come to the right place. http://www.criticalpathtraining.com/Schedule/Pages/090601-WC-SPA401-Webcast.aspx

June 15, 2009 – June 19, 2009 Dallas, Texas:

Todd Klindt and I are doing the SharePoint Survival Camp in beautiful Dallas Texas. http://www.criticalpathtraining.com/Schedule/Pages/20090615-SSC401-Dallas.aspx You can't have more fun (or learn more) about SharePoint administration in five days anywhere else.

June 22, 2009 – June 24, 2009 Boston, Massachusetts:

SPTechcon rules! Enough said. http://www.sptechcon.com Lots of top notch speakers talking about lots of fun things. Todd and I will be there doing a one day workshop and then some other scattered sessions. This will be a party. Use ShanesCows as your registration code to save some $$$.

I have a few other things in the hopper but that is enough for now.

Shane SharePoint Consulting