Jared Matfess's Blog

Having fun with SharePoint, Office 365, and Microsoft Azure

SharePoint February 2013 CU (+COD) breaks the RSS Viewer Webpart — April 23, 2013

SharePoint February 2013 CU (+COD) breaks the RSS Viewer Webpart

So I ran into a fun little problem a few days after patching our environment with the February 2013 CU + Critical “On-Demand” Update. Much like Microsoft we rushed to get the COD installed in our environment right away because we had a few highly visible sites experiencing the navigation node issue introduced back with the August 2012 CU. In true Microsoft fashion, I ran into a nugget where the latest patch broke some legacy functionality.

This time around the poor RSS Viewer Webpart died a strange an horrible death for non-anonymous sites. Just so we’re all playing with the same equipment.. We’re running Claims, Kerberos, and good ol’ fashioned 2010 Enterprise bits. When I say it breaks for non-anonymous sites, I really mean that when the webpart is on a page that is not set for anonymous it will not render the RSS feed. I’m not saying that it breaks for authenticated RSS feeds as inaccurately described during the Todd Klindt netcast, but rather when it’s placed on a non-anonymous site/site collection.

Luckily my man Srinivas from the Microsoft Product Team was very aware of this latest bug. He was able to provide us with a fix which I’d like to share with you the Internet..

Add this goodness to a CEWP on your page.. (Hide the titlebar unless you set it to Todd Klindt rocks)

function CustomUpdateFormDigest()
{
if(window._spPageContextInfo != null)
{
var $v_2 = window._spPageContextInfo;
var $v_3 = $v_2.webServerRelativeUrl;
var $v_4 = window._spFormDigestRefreshInterval;
UpdateFormDigest($v_3, $v_4);
}
}
CustomUpdateFormDigest();

As Todd Klindt always says.. Only patch if you absolutely need to and only hit up Production after some pretty rigorous testing..

Watching Todd Klindt’s Netcast on your Roku — March 12, 2013

Watching Todd Klindt’s Netcast on your Roku

toddLike dozens of other SharePointers around the world, I find myself locked into Todd Klindt’s Netcast. Now you might ask yourself, what could be more fun than hanging out in the chat and watching Todd fumble with webcams & microphones? Watching Todd Klindt on your 50″ plasma!

If you’ve got a Roku you can add the hidden UStream channel by following these 4 simple steps:

  1. Goto roku.com
  2. Login with your account credentials
  3. Scroll down to “Manage Account”, click “Add a Private Channel”
  4. The channel code for UStream is IN4DN.

Once you’ve got it added, bring it up and do a Search for “Todd Klindt”. The only gotcha is you won’t return any results until after the netcast has started.

SharePoint 2010 People Picker is having a hard time finding people! — February 26, 2013

SharePoint 2010 People Picker is having a hard time finding people!

Working with Premier Support today (on a seemingly unrelated issue) I stumbled upon some very interesting functionality which seems to have alleviated some pretty serious SharePoint People Picker problems. Imagine yourself in a scenario with a lot of user domains and WINS not working 100% like it should. When WINS fails, SharePoint tries to do a NetBios broadcast which doesn’t make it outside the subnet. So what you’ll find is SharePoint’s People Picker craps out, and not in a good way.

For awhile there we tried the searchadforests command which in a lot of ways didn’t make sense because we already had 2-way trusts with all the domains we were trying to communicate with. We limped along with people picker taking 60-90 seconds to resolve users. It was faster at resolving Domain\User therefore that was the guidance we provided to most site collection admins.

Previous attempts at gaining help from Microsoft resulted in a recommendation to perform domain consolidation, which in a large organization isn’t helpful.

Ironically enough, the SharePoint August 2012 CU includes some new functionality outlined below. As  a point of reference, our people picker is now humming between 5-15 seconds. I really wish I knew about this fix back in October when we rolled the August 2012 CU out to our environment.

======== Outline of issue documented in August 2012 CU ==========

The issue is caused when you click ok, People Picker makes a NetBIOS call to try to resolve the domain name.  Since the customer does not have WINS set up, a NetBIOS broadcast is done.  This fails to find the trusted domains because broadcasts are not allowed outside of the subnet.

This issue has been resolved and is included in any Cumulative Update after the August 2012 CU

http://support.microsoft.com/kb/2687339/EN-US

After you install the CU, you must run some PowerShell to enable the fix:

In order to use people picker without NETBIOS or WINS enabled you have to specify the domains you want to resolve users from using PowerShell explicitly on every web application.

After you installed the hotfix there is a new property which contains the NetBIOS name of a domain which you need to specify for the people picker settings for each web application.

This means that you have to list each of your trusted domains in the people picker settings, you cannot just specify a forest and have SharePoint resolve all domains from it.

Using PowerShell you can set the domain properties based on this sample.  The places where you need to enter your own values are in bold.

Add-PSSnapin Microsoft.SharePoint.PowerShell

# enable the global setting in the farm.  You only need to do this part once.
$farm = get-spfarm
$farm.Properties
$farm.Properties[“disable-netbios-dc-resolve”] = $true
$farm.Properties
$farm.Update()
# Handle one webapplication
$wa = Get-SPWebApplication http://yourwebapplicationurl
# Display current settings
$wa.PeoplePickerSettings.SearchActiveDirectoryDomains
# Save current settings to text file
$wa.PeoplePickerSettings.SearchActiveDirectoryDomains | out-file pp_settings_before.txt
# Clear the list
$wa.PeoplePickerSettings.SearchActiveDirectoryDomains.Clear()

# You need to repeat the following block for all the domains you want People Picker to work for on this particular web app
# ——————————————————————————————————————————
$newdomain = new-object Microsoft.SharePoint.Administration.SPPeoplePickerSearchActiveDirectoryDomain
$newdomain.DomainName =‘oneDomain.corp.contoso.com’;  # specify the fqdn
$newdomain.ShortDomainName =’oneDomain‘; # specify the netbios name

# =====================================
# This section is only required if there is a one-way trust to the domain and the application pool account does not have access

# First you have to run setapppassword on every server in the farm.
# This sets the encryption key used with the password you enter for the account you specify for $newdomain.loginname
stsadm -o setapppassword -password <password>
# Where <password> is any string you want to use as an encryption key.
# This needs to be run on every server using the same value for <password>

$newdomain.loginname = ‘oneDomain\userName’ # Specify an account that has access to the remote domain
# Do not change anything in the next two lines, it will prompt you to enter the password.
[System.Security.SecureString]$secureStringValue = Read-Host “Enter the account password: ” -AsSecureString
$newdomain.setpassword($secureStringValue)
# =====================================

$wa.PeoplePickerSettings.SearchActiveDirectoryDomains.Add($newdomain)
# Repeat end
# ——————————————————————————————————————————-

# Finally save settings for the web app
$wa.update()


You have to do this for each web application individually to enable the fix.

 

Workaround

If you can’t install the August 2012 CU right away, this workaround can be applied.  It essentially caches domain resolution info for the NetBIOS domain name in the Netlogon service and makes Nltest /dsgetdc:<DomainShortName> work.  If you get that to work, People Picker should also work.

1.  Create a batch file that contains the following commands for each external domain:
Nltest /dsgetdc:ExternalDomainName.FQDN
Nltest /dsgetdc:ExternalDomainName

Example:
Nltest /dsgetdc:Global
Nltest /dsgetdc:Global.Contoso.com
…and so on for each domain…

2. Run this batch file as a scheduled task every 15 minutes on each WFE.  This should keep the Netlogon cache populated, and should prevent the error from occurring.