PowerShell v3 & SharePoint 2010

I’m finding more and more that I’m late to the party for some things in SharePoint.

Apparently, SharePoint 2010 isn’t compatible with PowerShell v3.

Basically, when you try to use the SharePoint 2010 Management Shell you’ll be greeted with this:

clip_image001

Once you encounter this lovely error you’ll think you’ve done something horribly wrong. Is something up with your account? Did you break something? Are you losing it?

Nope to all of the above.

To get around this, type: powershell –v 2

Then hit enter. You now have regular ole PowerShell loaded. You’ll have to load the SharePoint snap-in if you want to do anything with SharePoint though. For anyone who may need it, the snap-in is:

Add-PSSnapin Microsoft.SharePoint.PowerShell

You can check out all the details here in this Connect article:

http://connect.microsoft.com/PowerShell/feedback/details/746908/powershell-3-0-and-sharepoint-2010

Hopefully this gets fixed in the next CU.

Search adventures with SSRS in Integrated Mode

At Trek we’re all about the BI. Just so happens I sit within the BI team so it was no surprise when Steve wanted to go with all the BI tools. PowerPivot and PerformancePoint were already setup before I got there. With SQL 2012 we get an overhauled instance of SSRS in Integrated mode and the newly introduced Power View. SSRS is now a Service App rather than a separate application so it makes deployment a lot easier. I won’t bore you with the details of installing as you can find all sorts of other bloggers walking you through the steps. What most bloggers don’t cover are the details of searching for .rdl’s.

Installation is pretty easy and getting your report libraries up and running are relatively straightforward. We even managed to create a few shared data sources and reports the day we went live. Real “Ready, Fire, Aim” type stuff. We happened to do the install on a Friday so we didn’t really put everything through its paces until Monday. When we began emailing links to rdl’s around we started getting complaints that users couldn’t see these reports. In addition, rdl’s weren’t showing up in search results.

Now what?

Posted this to the technet forums: LINK. Nauzad was pretty helpful in his reply in pointing me in the right direction. Come to find out, rdl’s are not extensions SharePoint search crawls by default. That’s an easy fix. Navigate to Central Admin > Manage Service Apps > Search Service App > File Types > add “rdl” and you’re golden. Kick off an incremental crawl and you should start to see rdl’s showing up in your results.

But I also noticed that only Full Owners, Site Collection Admins, and Farm admins were seeing reports in search results and in the libraries themselves.

Based on my research for the search issue I found that Report Libraries rely heavily on Publishing. Because of this, only those with Full Control rights and Site Collection Admins or Farm admins will see the rdl’s until they’re published, but it doesn’t stop there. You also have to publish the data source file as well. After some trial and error we figured this all out.

It’s relatively easy to get around the publishing requirement. Navigate to the Library Settings > Advanced Settings > check the box for “all users can see draft items.” Doing so will make all reports and data sources viewable as well as surface all reports in search regardless of published status.

For now, we’ve made the intentional decision to leave publishing on as it will allow use to security trim who has access to publish (accurate) reports and provide layer of oversight.

Issues adding add’l SharePoint server when using SP1 media

Few months back we added an app server to our farm, and – as always – it turned out to be an adventure.

Got a fresh Windows Server 2008 R2 install, joined to the domain, and applied all pertinent hotfixes and patches. While things were installing I downloaded the latest .iso’s from Volume Licensing. I went with the SP1 .iso’s as I figured this would be fine since the farm was already well past SP1. Save some time right?

Popped the dvd’s in the server and away we went. Install went fine with SharePoint so I moved on to the Office Web Apps. No incident there either.

I started up the Products Configuration Wizard and tried to join the box to the farm when I ran across an (in)convenient message telling me the Office Web App language server proofs we’re missing. But didn’t they install when I laid down Office Web Apps? What gives!?!

I commenced to Googling and I ran across this:

http://social.technet.microsoft.com/Forums/en-AU/sharepointadminprevious/thread/7f728f00-2283-4fe2-9134-f31bdf9cefb6

Looks like the slipstream installers are broken. I would take a guess and say Microsoft won’t be fixing them any time soon either.

Needless to say, I ended up reformatting the hard drive and starting over. I downloaded the pre-SP1 media and installed in the following order: SharePoint 2010 pre-SP1 > Office Web Apps pre-SP1 > SharePoint 2010 SP1 > Office Web Apps SP1 > SharePoint June 2011 CU > Current SharePoint CU. Took considerably more time, but it joined the farm no problem.

Moral of the story here is if you stood up your farm prior to SP1 with Office Web Apps, and you want to add another server to the farm you’ll need to do so following the procedures I went through.

Anyone else run into this?

June 2012 CU build number discrepancy

So tonight I just finished applying the June 2012 CU. I took a look in Central Admin’s “Servers in Farm” page and noticed that the build number was 14.0.6123.5000. According to a variety of SharePoint heavyweights’ blogs and MSDN, it should be 14.0.6123.5002.

I ran and reran PSConfig 3 times. Still no change in the build numbers. WTF!

Say What!?!

Event Viewer was fine. ULS was fine. The sites were fine. But I was starting to feel a twinge of panic.

Come to find out the last number in the sequence is the revision number. I ran across this TechNet post that put my mind to ease: http://social.technet.microsoft.com/Forums/en/sharepoint2010setup/thread/f004c2c8-3614-41ab-aca5-cff836d8ac5d

The poster with the answer mentions the syntax for a build number is Major (14), Minor (0), Build (6123), Revision (5000/5002). From now on I’ll pay attention to the third number in the sequence. … Microsoft Shenanigans win again.

Solving Double authentication prompt with Document Libraries in SharePoint for Internet Sites

Ran into this issue while I was on vacation. Dawn loved that while I’m in paradise, I break out my laptop to diagnose the issue. That took some serious explanation.

Anyways, I have an internet site deployed on SharePoint For Internet Sites (FIS). Although the site is setup for anonymous users we have a secured document library using a custom claims provider. The unfortunate thing I’ve found is that Office docs are not claims aware. What this means is that a user could login to the site using the custom claims provider, navigate to the doc library, click on a document, and they’re hit with another authentication prompt:

clip_image001

But they’re already logged in. What gives!

One thing to keep in mind with the double auth is that the user will only be required to do this once as it appears a cookie is cached in Office, but the particular site in question users typically only open one document at a time and then go on their merry way. So the double authentication is not gonna fly.

Workaround: use _layouts/download.aspx

I created a separate links list and created links to each file. The syntax you should use is as follows:

http://site.com/_layouts/download.aspx?SourceURL=%5Blibrary name]/[file name.extension]

Using the download.aspx convention causes SharePoint to use a different web service to deliver the file to the user. It adds a few steps for the admins but I’d rather make my life harder than make the site user’s life hard. If anyone knows a different way on how to solve this problem I’m all ears.

Troubleshooting SharePoint Timer Service Issues

From time to time I’ll come into work and notice that the Timer Service will be stopping unexpectedly. Every minute or so the timer service will stop and the server will start it again within another minute or two. It’s quite annoying and I’ve spent many a wasted morning tangling with it.  This post will be continually updated as I wrestle with the beast. Here are the steps I have so far. Start at #1 and work your way down until the problem fixes itself. Try to give about 5-10 minutes between each step:

  1. If you notice in the service console that the timer service is currently running hit “Restart the service”
  2. Do a full stop then start of the Timer Service
  3. Clear timer cache on farm (link)
  4. Update spfarmacc credentials
    • stsadm -o updatefarmcredentials -userlogin domain[timer service account] -password <>
  5. Check to make sure the ForeFront Identity Manager is running on your Sync server

Will continue to update with steps as I learn more.