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:


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:


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:


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:


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.

Event IDs 8311, 6803, 6110, and 6801 after new SSL certs installed and December CU

Read Technet Forum HERE

Read Stackexchange post HERE

About a week ago I installed new SSL certificates. Few days after that I configured the export thumbnailPhoto attribute for the User Profile Sync. I’ve never actually been able to successfully export the photos into AD. I see the following error in both the Event Viewer and the ULS logs:


An operation failed because the following certificate has validation errors:nnSubject Name: CN=[REDACTED], OU=Domain Control Validated – QuickSSL(R) Premium, OU=See http://www.geotrust.com/resources/cps (c)11, OU=2945119243, O=[REDACTED], C=US, SERIALNUMBER=[REDACTED]nIssuer Name: CN=GeoTrust DV SSL CA, OU=Domain Validated SSL, O=GeoTrust Inc., C=USnThumbprint:[REDACTED] nnErrors:nn SSL policy errors have been encountered. Error code ‘0x2’..

Not much help there. Contacted MS support and was told to install the latest CU (December 2011). Tested the CU earlier this week and decied to install during my change window yeseterday. Completed with no trouble and checkout went fine. I then try to kick off a Full Sync and now I’m seeing the 3 following Events in the logs:


The management agent “MOSS-[GUID]” failed on run profile “MOSS_FULLIMPORT_[GUID]” because the server encountered errors.


The management agent “MOSS-[GUID]” step execution completed on run profile “MOSS_FULLIMPORT_[GUID]” but the watermark was not saved.

Additional Information

Discovery Errors : “0”

Synchronization Errors : “0”

Metaverse Retry Errors : “0”

Export Errors : “0”

Warnings : “0”

User Action

View the management agent run history for details.


The extensible extension returned an unsupported error.

The stack trace is:

“System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. —> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.

at System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, Exception exception)

at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)

at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)

at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)

at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)

at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)

at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)

at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)

at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)

at System.Threading.ExecutionContext.runTryCode(Object userData)

at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)

at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)

at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)

at System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size)

at System.Net.PooledStream.Write(Byte[] buffer, Int32 offset, Int32 size)

at System.Net.ConnectStream.WriteHeaders(Boolean async)

— End of inner exception stack trace —

at System.Net.WebClient.DownloadDataInternal(Uri address, WebRequest& request)

at System.Net.WebClient.DownloadData(Uri address)

at Microsoft.Office.Server.UserProfiles.ManagementAgent.ProfileImportExportExtension.DownloadPictures(ProfileChangeData[] profiles)

at Microsoft.Office.Server.UserProfiles.ManagementAgent.ProfileImportExportExtension.Microsoft.MetadirectoryServices.IMAExtensibleFileImport.GenerateImportFile(String fileName, String connectTo, String user, String password, ConfigParameterCollection configParameters, Boolean fFullImport, TypeDescriptionCollection types, String& customData)

Forefront Identity Manager 4.0.2450.34”

Any insight? I’ll still continue to work with the MS Case Engineer but wondered if anyone has seen something similar. I’ll post the outcome when/if we ever get there. 😉

Updated – Issue Solved!

So the issue was the SSL certificate after all. I have 2 web apps on 1 server. I only serve up one of those web apps though and stop the other site in IIS. Because both apps (i.e. sites) are binded to port 443 they can’t have different certs. Only 1 cert to 1 port. (Note: we’ll be adding another virtual NIC which will alleviate this issue but I’ll cover that some other day). So the My Site web app – which is stopped – has the wrong cert applied but I don’t care since it’s stopped in IIS. Looks like SharePoint does care. Each time I attempted to run a Full Sync it would choke on the cert because it didn’t match the web app’s URL. Applied a wildcard cert and magically everything worked. I’ll have to manually switch the certs over in order to complete the Full Sync until the virtual NIC is added.