Data encoding in the SharePoint Profile Service

I was goofing around with a PowerShell script that would compare all of the SharePoint Profile Properties for a single user profile with their mapped counterparts in AD. If you’ve used FIM and 2010 long enough, you just get to the point where you don’t trust it…at all…ever.

Sounds pretty simple right? Connect to the profile service, get the profile properties, fire up Get-ADUser and compare. Bang, done. Or maybe not…

I started noticing that for some fields, the compare was coming back $false, when it should have been $true. I figured there were control characters in the fields, either in AD or SharePoint so I stripped everything out I could think of, no luck. I counted the number of characters in each object property, they were the same. Hmmm…

Then I noticed that all of the failures had characters like “&” in them. So what, I mean, & is & right? Wrong. It would appear that when data is written to the SharePoint profile, it’s encoded in ASCII. When data is written into AD (or everything else), it’s UTF-8. So, since ‘&’ is different in ASCII than it is in UTF-8, the compare fails. Great, awesome, perfect. Thanks SharePoint builders…

Fear not, there’s actually an easy way to fix this. Before you compare the SharePoint profile property with what’s in the AD property, just run the ‘ole “.Normalize(“FormKD”) method on the SharePoint property, that should take care of it. For example, the “Title” field in SharePoint (assuming $spProfile is an object that contains the user profile from SharePoint):

($spProfile[‘Title’].Value).Normalize(“FormKD”)

And you’re done…

Broken SP1 Language Packs

Many months ago, we battled an issue in RTM SharePoint 2013 where if you installed any additional language packs, and went to Central Admin, and tried to change the ULS Logging Levels for Search, the options would be presented to you in the last language pack you installed. Neat…well, kinda, unless the last language pack you installed was Thai, and you can’t read Thai.

We opened a case and went through the Support Mazes until we finally convinced someone at Microsoft that this was a bad thing, and not “working as designed” (oh those conversations were epic).

To our amazement, they fixed the issue in the October 2013 CU. Nice, done and done.

Now we install the SP1 patches for the language packs (after installing SP1), and guess what? You guessed!, the issue is back. So if you’ve installed SP1, and installed SP1 for any additional language packs you have, bop into Central Admin, click on Monitoring, then Configure Diagnostic Logging, the open up Search. Enjoy.

A side note, in our farms the last language pack we installed was German, and I’m not sure what “Fuzzynamenssuche” is, bit it’s hilarious…

I’ll post back when we make it through the support maze and figure out when/if this will be fixed…again.

SP1 Re-released

Microsoft has fixed the ugliness in the original SP1 patch for SharePoint 2013 and Office Web Apps 2013. I’m sure it’s fine now, download it, install and PSConfig the heck out of your farms.

I’ll be at the PowerShell.org Summit the week of April, 28th. Making fun of the guys talking about PowerShell and SharePoint is my life.

SharePoint 2013 SP1 Yanked!

Microsoft has found a bug in SP1 for SharePoint 2013 and has pulled it from the download site. For those of you like me that went ahead and installed it, they are working on a KB to correct the issue. It’s nothing major, just a small issue where you will never be able to patch your farm again…ever.

If you’re just about to click on the exe to start the SP1 install, I would go ahead and put the mouse down, and slowly back away from the keyboard.

Pulling a SP is new. Makes me wonder how they addressed this in O365…

Official Download Site:
http://support.microsoft.com/kb/2817429

Distributed Cache Services – And Why Not To Ignore It

When I first heard about the Distributed Cache Service in SharePoint 2013, I wasn’t paying as much attention as I should have, and my brain filtered all of the “Now, you want to think about this beast” talk I was hearing. Well, now I’m revisiting the DCS and realizing that if you’re going to build a multi-server farm, you should probably put some effort into how you’re going to make DCS work.

Initially, my brain heard “The DCS caches authentication information so you no longer need to set persistence on your VIPs.” This is correct, it does, but it also plays a massive role in the Social aspects of SP2013.

Fair warning, no whining about “Oh I broke DCS when I patched”, or “Why doesn’t my NewsFeed app update correctly”. You break it, you buy it…

Testing Webapps On Each SharePoint Server

I love single line PowerShell commands. Scripts can be boring, but it you can condense everything down to a single line, you sir, rock.

If you’re running a multi-server farm and using a load-balancer to handle getting the web requests to a Front End servers, you’ll sometimes (always) really like to know if the webapps are responding correctly on each server. If you’re like me, you place self-referencing host file entries on each server for each Web Application. No sense in having the servers send WFE request back to the load-balancer. And, magically, that’s a pre-requisite for this PowerShell command running. Without the host file entries on each server, the web requests will just go to the load-balancer, and you’ll never figure out who’s working and who’s not.

Log on to each of your SharePoint servers and fire up the handy-dandy SharePoint Management Console. Once you’re there, fire off this command:

Clear-Host;Get-SPWebApplication | Select -expand URL | %{$wa= $_;$request = [System.Net.WebRequest]::Create($_);$request.Timeout = 30000;$request.UseDefaultCredentials = $true;Try{$webcall = ($request.GetResponse());Write-Host "Site:$($webcall.ResponseUri) -- StatusCode $($webcall.StatusCode)";Write-Host "`r"} Catch [system.exception] {Write-Host "$wa Failed -- $($error[0].Exception.Message)";Write-Host "`r"}}

This will pull each URL from SharePoint and spin up a web request and show you the feedback.

Note: You may need to adjust the timeout variable in the web request if your app pools have spun down and they need longer than 30 seconds to come back up.

Hope it helps!