Way too much debate out in Twitterville and through other folks that are just flat out wrong. Why wrong? Well in a test lab environment I have no problem with this but folks tend to get lazy and that is where you run risks in your production environment.

Now im not going lament on the whys as this was finely detailed by Spence Harbar and let me quote from his post

"What is the issue?
Windows Server 2003 SP1 introduced a loopback security check. This feature is obviously also present in Windows Server 2008. The feature prevents access to a web application using a fully qualified domain name (FQDN) if an attempt to access it takes place from a machine that hosts that application. The end result is a 401.1 Access Denied from the web server and a logon failure in the event log.

Unfortunately 401.1 is not really helpful as this error code means there is a problem with the user credentials. Of course, the HTTP spec doesn't know about security features in a vendor's implementation so there can't be a HTTP error code for such a feature. This can lead to much banging of the head on the desk. It's one of numerous causes of the 401.1 which are nothing to do with invalid credentials (e.g. attempting to use Kernel Mode Authentication with domain account in IIS7).

What this means is that when you browse a SharePoint Web Application which uses a fully qualified domain name from a WFE in the farm you will get a 401.1. This is very annoying on a development box, or when testing locally, or in other SharePoint specific scenario "

Ok so we have some background info the one thing my buddy doesn't do is show us how. Now the crux is that in http://support.microsoft.com/kb/896861 Microsoft details two such fixes for this. I am going to screenshot the right way to do this.

First off we need to add the following registry key to kick this off

In the screenshot above under HKEY_LM\system\CCS\Services\Lanmanserver\param we will create a dword DisableStrictNameChecking.  Add a value of 1 to this new entry,

Exit Registry and reboot your box

Reopen Registry and nav to HKEY_LM\System\CCS\Control\LSA\MSV1.0 and create the following key as shown below

Once there simply open this Multi-String Value and enter the sites you want included… ie your SharePoint sites J

No need for URLs here.. simply type in (for this example) connect.contoso.com on a separate line your next site and on and on down the line.

The beauty of this method is that once you add this key you wont have to reboot your box after adding these entries.

So hope this post along with Spences stops the silly questions and even more so… wrong answers folks are following

<A Microsoft PFE’s Note from the Field>

So in my day to day SharePoint support endeavors one of the
classic cases that come in from time to time is customers trying to implement
Kerberos into their Farms.   One of the
issues I see pop up a lot is duplicate SPN’s.  

The classic method (via the command line) is to run the
following command to create an SPN:

Setspn –a http/<FQDN or Netbios Name>  Domain\usercredential

For example   Setspn –a
http/connect.sharepoint.com
sharepoint\content1 

This would create an SPN to be used to create a valid
Kerberos ticket for the http/connect.sharepoint.com  site.  
Easy stuff here and you can verify this by going into ADSIEdit and open
the properties for the Content1 Service Name.

But how do we get the issue with Duplicate SPN’s.   Usually this comes down to poor planning
before you turn on your computer.   Say
as an example (and one I see often) you didn’t think this through and plan your
AuthN properly.  Or say you just made a
simple “FatFinger” or had a “Brain Cramp”… it happens.   For illustration purposes lets go with the
idea that you created the above mentioned SPN but for some reason you tried to
run the Setspn command again using a different account.  Voila! that’s where we are in trouble.   In my example I created two SPN entries
pointing to the same site but I used two different service accounts.   SPContent and SPContent1.   As you can see in the screenshot below I get
an Event ID 11 thrown which if you can read the text is basically telling me
exactly what I need to know to go forward and fix the issue.

 
 
  So is there a way to verify this before I go and run the
command?   Absolutly.    If you enter the command Setspn –x you will
get a list of any duplicates that exist in your environment.

  Let’s take this one step further and combine
both the –A and the –X into a single FatFinger Proof method of creating our SPN’s

Operation ABORTED!!!   
So if we look at the above output were shown the same information as the
Setspn –x but we are also combining this with the ability to add an SPN.   In both of these outputs you can clearly see
that in my demonstration I tried to create an SPN for the same site
http/connect.sharepoint.com but I used separate accounts.    Also note that I can use the same account
for multiple hosts if I so choose.. in this case im using Spcontent1 for both
http/connect and http/my.   

So in a perfect world when you are doing this work and you don’t
have any duplicates you can use either the setspn –x initially to see if any
duplicates exist or do what I always do… use the setspn –s and cover everything
in one sweep.  In the above example if
there were no duplicates the process would successfully finish and presto chango
you have your SPNs created

Hope this helps someone out there J  Cheers!

In SharePoint 2010 we introduced FIM which acted as a broker of sorts when bringing profiles from AD into SharePoint.  One of the key reasons for this add was to allow companies to not only pull AD info into SharePoint but also to push information from SharePoint back to AD. This was a key change from Microsoft Office SharePoint Server 2007 or MOSS 2007 as we generally called it.  The synchronization method was a very simple one way pull from AD which didn’t allow a lot of flexibility.

One of the pains that were felt with User Profile Service Application (or UPSA, UPA, Dir Syncer or whatever folks like to refer to it) was that it required more steps to configure than just going into the UI and
clicking a couple buttons as we Admin types are generally fond of doing.   Early on in the process my buddy Spence wrote the manifesto on how to properly create this.  There was a lot of bad guidance floating
around out in the webosphere on how to do this and pretty much all of them were wrong.   As much as it pains me to admit as I don’t want to inflate an ego but one of the questions I would always ask
my customers when they deployed SharePoint 2010 went a little like this:

Me – Oh great it looks like you have every Service Application provisioned (this to me 99% of the time pointed me to the fact that they used the FCW (Farm Configuration Wizard) to deploy the farm)   More
to come from that another time but this is a bad plan for Production Farms.  Fine for Dev or Test but Prod….Please don’t do this.

Customer – Yep it was simple but I can’t seem to get the User Profile thing working

Me – did you follow any guidance out on the web for this? 

Customer – No I just let SharePoint handle it

Me – rubbing my hand through my hair wondering what a proper response would be while continuing to be a Trusted Advisor……

Me – You know we have a couple excellent documents out there that detail what needs to be done here to configure this.   Namely TechNet or my buddy with the sillypurple page  In fact if you follow
this guide step by step you will always have a successful experience in deploying UPA.

Getting back on track to the point of this post is to inform you that those guides are still fully relevant today in SharePoint 2013.  There is however one exception to this. Along with the previous mentioned method to Profile Synchronization we have also included the previous method of import…It’s called Active Directory Direct import and think of this as the lightweight import method.

The method of implementing this is not right in front of your face though.  When I first started looking at this I would have assumed that they would add this functionality at the point where you create your Profile Synch but this lives in a different area.  I will highlight both SharePoint 2010 and 2013 in the following screenshots to show this:

SharePoint 2010 (notice the arrow pointing to Configure Sync Settings)

 SharePoint 2013 (Notice that the screens look remarkably similar)

SharePoint 2010 (Configure Sync Settings)

SharePoint 2013 (Configure Sync Settings)

 As I am illustrating here this is where you would differentiate between the two methods. By default we are setting this for FIM but if you choose to go with AD Direct you would set this at this location.

One additional thing to note here is that in the previous version we had to have Replicate Directory Changes set via Delegate Control in Active Directory.  This is still a necessary step for either method you choose here.

Cheers!

 Additional Note:  Spence informed me that he recently put out an updated article
that can be found here

http://harbar.net/archive/2012/07/23/sp13adi.aspx

I wanted to post out a couple things that I have found recently that may cause some confusion when trying to integrate an Existing SharePoint 2010 Environment with FAST Search.

If you already have an existing Search SSA you can safely remove this once you install and configure your FAST environment.   This SSA is NOT needed.   FAST has two seperate SSA's:

FASTContent - This SSA will hold the Content Source for all the sites that will be crawled under the FAST Search Engine.

FAST Query - This SSA in simply responsible for the sps3://  (profile imports)

Now the confusion will arise when you create a new web application and expect it to go directly into the FAST Content SSA  Content Source.   It does not.   It will go directly to the FAST Query SSA Content Source.

What does all this mean?   RIght now you need to ensure that any sites that you want to crawl live inside the FAST Content SSA.   You will need to manually move any sites you create from the FAST Query to the FAST Content Content Source.

Just something to keep in mind.  Not a huge deal but will be another step for Admins to put on thier checklists.

Building a brand new SharePoint 2010 Environment?   Want to decrease some of the time for making
sure your environment is up to date with regards to versioning?    Slipstream your build.

In the following section I am going to detail how I build my
slipstreams… there are other posts out there that will be similar and may even include
shortcuts such as posting the bits directly to the update folder but I like to
be a little more hands on and in reality it does not take a lot of effort.  

New Environment

Download the SharePoint 2010 RTM Bits  (http://technet.microsoft.com/en-us/evalcenter/ee388573)

I shorten the name of the downloaded file before I begin to
something like SP10.exe and SFSSP1  this
will make it a bit easier on the typing.

Download the SP1 Bits. 

Although technically not necessary I will still download and
incorporate both the SharePoint and the SFS SP1 Bits into my slipstream.

http://www.microsoft.com/download/en/details.aspx?id=26623 

http://support.microsoft.com/kb/2460058

Same as with the RTM bits… I will shorten the names of these
files to help with typing.  SFSP1.exe and
OFFSP1.exe

Download the CU’s

http://support.microsoft.com/kb/2536599

http://support.microsoft.com/kb/2553931

Lets get busy

So this was the hardest part of the operation.   What I do next is create four folders and extract the bits for each into them.

SP1 – Folder names    OFFSP1  
SFSSP1

Command I run:   sp1.exe /extract:c:\OFFSP1    (where sp1.exe is the renamed executable and OFFSP1 is the folder I created and am extracting to.

                             Sfssp1.exe /Extract:c:\SFSSP1

I will do this for the Cumulative Updates as well.  

Once this is complete the SharePoint 2010 Installation
folder has a folder called updates.   I
am simply going to copy and paste the contents of each of the folders I extracted
directly into Updates.  

This concludes the Slipstream procedure.    Once complete you can go forth and install.    Your environment will be up to date and you wont have to go through the process of individually installing
patches and then remembering if you hit every server in the process…  It happens (unfortunately very often)

Additional reference information can be found here at my buddy Spence’s site http://www.harbar.net/archive/2011/06/30/327.aspx