Came across a problem recently while on site with a client which I have never come across before.
If you are trying to test your SharePoint Server web applications locally on a SharePoint server and you find that it is refusing to accept the locally logged on user or another user who should have access to the site by asking for your credentials 3 times before telling you that you don’t have access, it is because of a security feature within IIS which will not allow the use of integrated security for a hostheader that is not the server’s hostname.
Fortunately there is something you can do:
The feature is called “Loopback Security” and can be disabled through a registry key.
Create a new DWORD registry key called “DisableLoopbackCheck” in the location “HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa”, then set its value to “1”.
You should then be able to access the sites with host headers.
One of the things that annoys me about SharePoint is the way in which it automatically names the databases, even when you don’t use the wizard (don’t get me started on that).
One thing you can’t do when you run the configuration wizard to create a brand new farm is to specify the database name for the central administration database. Instead you end up with something like “Content_Admin_abcdefg0093857378383”, if this annoys you as much as it does me then there is a solution.
Open up Powershell and load the SharePoint addons (or start the SharePoint Powershell from the programs menu), then do the following:
- The first thing we need to do is get the ID for the database, the easiest way to do this is to type the following and locate the line with the Administration Content data base on it and copy the value from the ‘Id’ column:
- Next we need to load the database reference into a variable so that we can update the name
$admindb = Get-SPDatabase -Identity <Identity from step 1
- Change the name property of the new variable with the name you want the database to be called
$admindb.Name = “”
- Update the database (Note: this will update SharePoints record for the database but not the actual database, at this point central administration will become unavailable – see below)
- At this point Central Administration will no longer work as it doesn’t know the database exists, to correct this you first need to stop the following services so you can change the database’s actual name:
SharePoint 2010 Administration
SharePoint 2010 Time
- Using SQL Management Studio or an SQL Server client of you choice you can now update the name of the database, this must match the name that you specified in step 3 for the desired name.
- Finally start the two services we stopped in step 5 and everything will be back to normal only this time with a database name that hopefully makes sense and is named using a similar naming schema to the rest of your deployment databases.
Full PowerShell Prompts:
$admindb = Get-SPDatabase -Identity ""
$admindb.Name = ""