Friday, November 23, 2012

Reset Customized Master Page to the Original Version (Ghosting) in SharePoint 2010

When we develop a custom master page and use a feature to deploy it in SharePoint, custom master page will be stored in %Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\FEATURES\<feature name> folder. Then when new sites are created and set our custom master page as the master page, SharePoint keeps a reference to the file located in 14 hive no matter how many sites are created. This process of all site collections and sites pointing to one file is called Ghosting.

But if the master page is customized in SharePoint Designer or uploads a new version in the master page gallery of a site, SharePoint stores a modified version of the master page in the content database (Unghosting or Customizing). This process basically breaks the reference SharePoint keeps to the master page file on the 14 hive. That is why we see a warning message in the first time we customize a master page in SharePoint Designer 2010, saying that we are about to customize a page and it will no longer be based on the site definition. The reason for this behavior is not to affect other SharePoint sites that are still using the original master page.


When there are custom controls or webparts embedded to the master page and if we try to change the master page in SharePoint Designer or uploads a new version of master page in the master page gallery, it will break the whole master page and the site in most of the time. In case if that happens, we need a way to revert back to the original master page. One option is to use SharePoint Designer to reset the master page to its site definition.

Navigate to the master page -> Right click -> Reset to Site Definition 


This brings our site back to its original state and at the same time, creates a copy of our customized master page and places it in the Master Page Gallery. 


Original master page is in the ‘Approved’ status and new copy is in ‘Draft’ status.

Tuesday, October 23, 2012

Setup Multiple SharePoint Web Applications on Port 80 with Https Binding on Port 443

Approach described here involves Host Header names to host multiple sites from one IP address in IIS server.
Create Web Applications using Host headers
Create a SharePoint web application with the host header devint-wtu.navantis.com in port 80. So the URL for this web application will be http:// devint-wtu.navantis.com. Also I specified a name ‘WTU’ for the IIS web site as shown below.

Create another SharePoint web application with the host header devint-cpl.navantis.com in port 80.

So my web application listing in the central admin will look like as:

Update Host file
Then we have to map above web application URLs to the local loopback address. For that we need to update host file (C:\Windows\System32\drivers\etc\hosts) as below.

Create HTTPS binding
In order to enable Https browsing for these web applications on the default port 443, we have to add https bindings. For that we need a SSL certificate. We can create a self-signed certificate in the IIS by IIS Server -> Server Certificates -> Create Self-Signed Certificate. In my case I creates a certificate called *.navantis.com
Select the IIS Web site; select Bindings… from the action pane and use Add option to create an https site binding by specifying host name and SSL certificate as below.
Repeat the same procedure for each web application. Specify the correct host name of the web application.

Configure alternate access mappings
Go to ‘Application Management’ -> ‘Configure alternate access mappings’ in SharePoint central administration and use ‘Add Internal URLs’ option to create alternate access mappings for each web application. Map the correct https Url as below.


So the alternate access mappings listing will look like:

That’s it!
Note: Still you might not be able to browse these web applications (after creating site collections). In that case follow this article: Unable to browse SharePoint web site (http://onlinecoder.blogspot.com/2012/10/unable-to-browse-sharepoint-web-site.html)

Tuesday, October 2, 2012

Unable to Browse SharePoint Web Site from within the Server

I came across this scenario where I cannot browse my SharePoint web application; it asks for my credentials 3 times but doesn't render the site and also doesn't show any errors. Basically I had 3 web applications in the same server; setup using host names to run on port 80. The host file (C:\Windows\System32\drivers\etc\hosts) is modified to map my web application URLs to the local loopback address.

Host file
127.0.0.1       website1.myserver.com
127.0.0.1       website2.myserver.com
127.0.0.1       website2.myserver.com

When I check the Event Viewer of the SharePoint server, I found set of Audit Failure logs which seems to be relevant to this scenario.

General
Log Name:      Security
Source:          Microsoft-Windows-Security-Auditing
Date:             9/27/2012 11:39:15 PM
Event ID:        4625
Task Category: Logon
Level:            Information
Keywords:      Audit Failure
User:             N/A
Computer:      DERDEV02.domainx.local
Description:    An account failed to log on.

Subject:
          Security ID:             NULL SID
          Account Name:         -
          Account Domain:       -
          Logon ID:                0x0

Logon Type:                      3

Account For Which Logon Failed:
          Security ID:                      NULL SID
          Account Name:                  prasadw
          Account Domain:                DOMAINX

Failure Information:
          Failure Reason:         An Error occured during Logon.
          Status:                   0xc000006d
          Sub Status:             0x0

EventData
  SubjectUserSid S-1-0-0
  SubjectUserName -
  SubjectDomainName -
  SubjectLogonId 0x0
  TargetUserSid S-1-0-0
  TargetUserName prasadw
  TargetDomainName DOMAINX
  Status 0xc000006d
  FailureReason %%2304
  SubStatus 0x0
  LogonType 3
  LogonProcessName 
  AuthenticationPackageName NTLM
  WorkstationName DERDEV02
  TransmittedServices -
  LmPackageName -
  KeyLength 0
  ProcessId 0x0
  ProcessName -
  IpAddress 127.0.0.1
  IpPort 62970

Then I found that when we use the fully qualified domain name (FQDN) or a custom host header to browse a local Web site that is hosted on a computer that is running Microsoft Internet Information Services (IIS) 5.1 or a later version, we may receive this error. It says that this issue occurs when the Web site uses Integrated Authentication and has a name that is mapped to the local loopback address. Also if we browse the Web site from a client computer, we will receive this error message.

There are 2 workarounds proposed for this error in the Microsoft Support Article ID:896861 (http://support.microsoft.com/kb/896861)
Method 1: Specify host names
  1. Set the DisableStrictNameChecking registry entry to 1.
  2. Click Start, click Run, type regedit, and then click OK.
  3. In Registry Editor, locate and then click the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
  4. Right-click MSV1_0, point to New, and then click Multi-String Value.
  5. Type BackConnectionHostNames, and then press ENTER.
  6. Right-click BackConnectionHostNames, and then click Modify.
  7. In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.
  8. Quit Registry Editor, and then restart the IISAdmin service.

Method 2: Disable the loopback check
  1. Set the DisableStrictNameChecking registry entry to 1.
  2. Click Start, click Run, type regedit, and then click OK.
  3. In Registry Editor, locate and then click the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
  4. Right-click Lsa, point to New, and then click DWORD Value.
  5. Type DisableLoopbackCheck, and then press ENTER.
  6. Right-click DisableLoopbackCheck, and then click Modify.
  7. In the Value data box, type 1, and then click OK.
  8. Quit Registry Editor, and then restart your computer.

Thursday, September 27, 2012

SSL Site with Host Headers in IIS 7

We cannot use the IIS7 User Interface to add a host header to an SSL site binding. The Host name field will get disabled once we select the Type as https.

One way to add a host header to an SSL site binding is by using command-line tools. Another way is edit the applicationhost.config file directly.

1.  Add SSL bindings to your web sites with empty host headers
2. Find applicationhost.config file located in “C:\Windows\System32\inetsrv\config”. You need administrator permission to edit this file (Use Notepad in ‘Run as administrator’ mode )
3.  Search for the value ‘443’ in Find applicationhost.config file
4.  You can find “bindings” section inside the site node

5.  Add the required host header in bindingInformation property

6.  Save the applicationhost.config file
7.  Refresh IIS Manager and you can notice host header in https binding

Thursday, September 13, 2012

PowerShell Error in SharePoint Server - Cannot Access the Local Farm

I was using a PowerShell script to deploy my SharePoint solution in the development environment for some time now. But when I try to use the same script in a newly configured SharePoint environment I got the following error.

“Get-SPSolution : Cannot access the local farm. Verify that the local farm is properly configured, currently available, and that you have the appropriate permissions to access the database before trying again.”



In my deployment script I have used “Get-SPSolution” command and it seemed like this command was failing due a configuration error in the local farm. So I tried to re-run the SharePoint 2010 Products Configuration Wizard and got the following error.

“Failed to detect if this server is joined to a server farm. Possible reasons for this failure could be that you no longer have the appropriate permissions to the server farm, the database server hosting the server farm is unresponsive, the configuration database in inaccessible or this server has been removed from the server farm.”
























When I click “OK” on the popupbox, Database server and Database name were marked as Unknown and “Do not disconnect from this server farm” option was disabled.


Issue in my case:
Executing sp_helpserver in SQL Server management studio of the server gave me a wrong name as the server name and same wrong name as the network name of the server. (You will come across this scenario when the computer hosting SQL Server is renamed).

In addition to the above issue, the domain account I used to do the deployment didn’t have permissions to access the databases, even though it was added as a local administrator account of the server. 


Solution:
In order to correct the server name in the SQL server, first I used sp_dropserver command. This command removes a server from the list of known remote and linked servers on the local instance of SQL Server.
sp_dropserver 'WrongServer'

Then I used sp_addserver command to define the name of the local instance of SQL Server.  This command actually informs the new computer name to the instance of the SQL Server Database Engine.
sp_addserver 'CorrectServer'

Finally granting DB permission to the domain account solved my issue.