Custom access denied page SharePoint 2013

Last week I was trying to figure out a way to set up  a custom access denied page and found some useful information which I want to share.  Most of the clients and SharePoint users I spoke to always say they don’t want their site to look like SharePoint. When you do not have access to a SharePoint site then you will be directed to this page to request access. When you post a request it will show at the bottom of the message box.

accessdenied

In SharePoint 2013 this page can be easily customized. Below steps should be performed on all the web front ends.

  1. Go to C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\TEMPLATE\LAYOUTS
  2. Accessdenied.aspx page will be located here. I took out access AccessRequestsDialog div and added some text to AccessDeniedAdditionalDetails as below. Too small to read I guess , try zoom in please.
  3. accessdenied
  4. You can customize all you want here and create your own access request page.
  5. There is no need to reset IIS and this should take effect right away.
  6. If you do not want to change the existing SharePoint file which Microsoft does not recommend then you can create a folder in Layouts folder called “custom pages” and copy the accessdenied.aspx to this folder and make changes there. But SharePoint does not know about the new page. So you have to execute below power shell but running the SP management shell as farm admin . Set-SPCustomLayoutsPage -Identity “AccessDenied” -RelativePath “/_layouts/15/custompages/AccessDeniedNew.aspx” -WebApplication “http:/mywebapplication/”

Good to know details:

I have read few people saying that some times when you create a new folder and run power shell , the changes you mage will not take effect due to a bug. This happens is SharePoint 2013 SharePoint 2013 Custom Access Denied . And the solution to this is to install April 2014 CU.

cannot open central admin

Environment: SharePoint 2013 on windows server 2012r2

All of a sudden yesterday I was not able to open central admin. Browser returned 404. Tried IISreset , reboot server, application pools were fine, all the services seemed fine.

Looked in to the ULS error logs and found an error “An exception occurred when trying to issue security token: Loading this assembly would produce a different grant set from other instances. (Exception from HRESULT: 0x80131401).”

Posted on MSDN forums and received a suggestion about windows update. It seems .net update caused missing registry keys and the solution was to update the registry as below

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework’, create a new ‘DWORD (32-bit) Value’ named “LoaderOptimization” with a value 1.

‘HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework‘, create a new ‘DWORD (32-bit) Value’ named “LoaderOptimization” with a value 1.

MSDN forum research

 

cannot invoke webservices

As a part of SharePoint migration from 2010 to 2013 I was working on moving the webservices from dev to QA. Initially I thought of testing  few defaults like GetAccountName , GetSiteUsers but when I try to invoke I got the below error.

System.ServiceModel.EndpointNotFoundException: The message could not be dispatched because the service at the endpoint address ‘net.pipe://localhost/s4u/022694f3-9fbd-422b-b4b2-312e25dae2a2’ is unavailable for the protocol of the address.

Below are the steps I tried to resolve

  1. killed SMSSvcHost.exe process and then restarted Net.Tcp Listener Adapter service
  2. Reset IIS

Above steps did not help me but it did help others on the net.

Mine was SharePoint specific issue and SharePoint 2013 was claims only so I looked in the services on the central admin and saw that claims to widows token service was not running . I started this and my web services started working.

 

 

SSL

I was tasked to convert few http web sites to https and I took a long journey in to the world of secure socket layer and wanted to share what I learned. I will be quoting a lot in this article as there is plenty of info already out there. This article is just scratching the surface of SSL/TLS.

Communication travels in clear text with http protocol so for all the valid reasons it is sensible to convert it to https in which data in encrypted.

First of all you need a certificate to make an SSLconnection. Please read through the following links to understand a bit about certificates, https://www.verisign.com/en_US/website-presence/website-optimization/ssl-certificates/index.xhtml ,  https://www.globalsign.com/en/ssl-information-center/what-is-an-ssl-certificate/ .

Once you get a certificate from a trusted CA (certificate authority) then your client have the ability to trust the certificate or atleast can go through the process of trusting. You have to import the certificate in your web server, in my case it is IIS. For steps to do this check out https://technet.microsoft.com/en-us/library/cc732785(v=ws.10).aspx.

Now you need to create a https binding. Please check out http://www.iis.net/learn/manage/configuring-security/how-to-set-up-ssl-on-iis . This link also explains about certificate import and gives you other related info.

At this point if your firewall is set up to accept SSL traffic then you should be able to access the sire using https.

What happens when the communication actually starts.

Say your sitting in starbucks unsecured network and accessing your newly created https site. The first thing the client does is a handshake with the server. Client site authentication follows below steps

  1. The client sends the server the client’s SSL version number, cipher settings, session-specific data, and other information that the server needs to communicate with the client using SSL.
  2. The server sends the client the server’s SSL version number, cipher settings, session-specific data, and other information that the client needs to communicate with the server over SSL. The server also sends its own certificate, and if the client is requesting a server resource that requires client authentication, the server requests the client’s certificate.
  3. The client uses the information sent by the server to authenticate the server (see Server Authentication for details). If the server cannot be authenticated, the user is warned of the problem and informed that an encrypted and authenticated connection cannot be established. If the server can be successfully authenticated, the client proceeds to step 4.
  4. Using all data generated in the handshake thus far, the client (with the cooperation of the server, depending on the cipher being used) creates the pre-master secret for the session, encrypts it with the server’s public key (obtained from the server’s certificate, sent in step 2), and then sends the encrypted pre-master secret to the server.
  5. If the server has requested client authentication (an optional step in the handshake), the client also signs another piece of data that is unique to this handshake and known by both the client and server. In this case, the client sends both the signed data and the client’s own certificate to the server along with the encrypted pre-master secret.
  6. If the server has requested client authentication, the server attempts to authenticate the client (see Client Authentication for details). If the client cannot be authenticated, the session ends. If the client can be successfully authenticated, the server uses its private key to decrypt the pre-master secret, and then performs a series of steps (which the client also performs, starting from the same pre-master secret) to generate the master secret.
  7. Both the client and the server use the master secret to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity (that is, to detect any changes in the data between the time it was sent and the time it is received over the SSL connection).
  8. The client sends a message to the server informing it that future messages from the client will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the client portion of the handshake is finished.
  9. The server sends a message to the client informing it that future messages from the server will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the server portion of the handshake is finished.
  10. The SSL handshake is now complete and the session begins. The client and the server use the session keys to encrypt and decrypt the data they send to each other and to validate its integrity.
  11. This is the normal operation condition of the secure channel. At any time, due to internal or external stimulus (either automation or user intervention), either side may renegotiate the connection, in which case, the process repeats itself.

During the SSL handshake, the server sends the client a certificate to authenticate itself. The client uses the certificate to authenticate the identity the certificate claims to represent. An SSL-enabled client goes through these steps to authenticate a server’s identity:

  1. Is today’s date within the validity period? The client checks the server certificate’s validity period. If the current date and time are outside of that range, the authentication process does not go any further. If the current date and time are within the certificate’s validity period, the client goes on to step 2.
  2. Is the issuing Certificate Authority (CA) a trusted CA? Each SSL-enabled client maintains a list of trusted CA certificates. This list determines which server certificates the client will accept. If the distinguished name (DN) of the issuing CA matches the DN of a CA on the client’s list of trusted CAs, the answer to this question is yes, and the client goes on to step 3. If the issuing CA is not on the list, the server is not authenticated unless the client can verify a certificate chain ending in a CA that is on the list.
  3. Does the issuing CA’s public key validate the issuer’s digital signature? The client uses the public key from the CA’s certificate (which it found in its list of trusted CAs in step 2) to validate the CA’s digital signature on the server certificate that is being presented. If the information in the server certificate has changed since it was signed by the CA, or if the CA certificate’s public key doesn’t correspond to the private key that was used by the CA to sign the server certificate, the client does not authenticate the server’s identity. If the CA’s digital signature can be validated, the client treats the server’s certificate as a valid “letter of introduction” from that CA and proceeds. At this point, the client has determined that the server certificate is valid. It is the client’s responsibility to take step 4 before it takes step 5.
  4. Does the domain name in the server’s certificate match the domain name of the server itself? This step confirms that the server is actually located at the same network address that is specified by the domain name in the server certificate. Although step 4 is not technically part of the SSL protocol, it provides the only protection against a form of security attack known as a “Man-in-the-Middle Attack.” Clients must perform this step and must refuse to authenticate the server or establish a connection if the domain names do not match. If the server’s actual domain name matches the domain name in the server certificate, the client goes on to step 5.
  5. The server is authenticated. The client proceeds with the SSL handshake. If the client does not get to step 5 for any reason, the server that is identified by the certificate cannot be authenticated, and the user is warned of the problem and informed that an encrypted and authenticated connection cannot be established.

What to watch:

  1. Https will add extra stress on the server so be mind full of resources.
  2. It will breaks the cache to through testing is required.
  3. Be mind full of relative links on your site and make sure all these are changed to https.
  4. check out https://www.quora.com/Are-there-any-disadvantages-to-using-HTTPS-instead-of-HTTP , https://blog.nexcess.net/2014/09/03/the-pros-and-cons-of-implementing-ssl-https/ .

Ref:

https://support.microsoft.com/en-us/kb/257587

https://support.microsoft.com/en-us/kb/257591

http://robertheaton.com/2014/03/27/how-does-https-actually-work/

 

 

 

Install office webapp server for SP2013

It is straight forward and there are lot of articles explaining it but my case is little different. Office web app server was installed and configured to run with http and SP dev server was using it. I will discuss how to change this to https, which in turn covers how to install office webapp server (WAC) for SharePoint 2013 to work internally and externally. If you are installing from scratch then you can follow  https://technet.microsoft.com/en-us/library/jj219455.aspx?f=255&MSPPError=-2147217396 . This will install office webapp server and you will need to do few more steps for it to work with SharePoint.

To remove the existing http configuration.

  1. Remove-OfficeWebAppsMachine
  2. Insall SSL certificate on the office web app server IIS. One way to do it Go to IIS ->Server certificates -> Import or google it.

Create a new office Webapps farm with https

  1. New-OfficeWebAppsFarm -InternalUrl “https://server.contoso.com”  -ExternalUrl “https://wacweb01.contoso.com” -CertificateName “OfficeWebApps Certificate” -EditingEnabled
  • –InternalURL is the fully qualified domain name (FQDN) of the server that runs Office Web Apps Server, such as http://servername.contoso.com.
  • –ExternalURL is the FQDN that can be accessed on the Internet.
  • –CertificateName is the friendly name of the certificate.
  • –EditingEnabled is optional and enables editing in Office Web Apps when used with SharePoint 2013. This parameter isn’t used by Lync Server 2013 or Exchange Server 2013 because those hosts don’t support editing

For the ease  of setting up internal and external URL’s I choose it to be the same. Lets say https://officewebapp.domainname.com . While settign up DNS you can make this as alias and use fully FQDN to point to the office server. You need to set this up in the internal DNS and external DNS. So I command I used to create office webapps Farm is

New-OfficeWebAppsFarm -InternalUrl “https://officewebapp.domainname.com” -ExternalUrl “https://officewebapp.domainname.com” -CertificateName “OfficeWebApps Certificate” -EditingEnabled

2. After its installed you can verify by going to https://officewebapp.domainname.com/hosting/discovery and you will see an XML. Or you can use Get-OfficeWebAppsFarm power shell command and verify all the details.

Set up Sharepoint to use https office webapps

  1. Creating biding using  New-SPWOPIBinding -ServerName officewebapp.domainname.com
  2. check the Zone using Get-SPWOPIZone . It will show only internal.
  3. Set up external Zone using Set-SPWOPIZone -Zone “external-https”

Verify 

Make sure you aren’t logged on as System Account because you won’t be able to edit or view the documents with Office Web Apps. You should be able to open office docs internally or externally in the browser.

Restoring SharePoint WebApp

I have seen all kinds of issues while moving sites, webapps  from one environment to other. If your restoring a webapp on the same farm then you might get away with minimum trouble shooting but if its a different farm then you are at the mercy of google.

You can start with below trouble shooting steps.  I am assuming that you are restoring a webapp from Farm A to Farm B running with different service accounts.

  1. Backup the DB on Farm A and Restore it to SQL server of Farm B.
  2. Add all the service accounts from Farm A to Farm B and assign these accounts same permissions like that of Farm A, including local server admin permissions. DO NOT CHANGE ANY EXISTING SERVICE ACCOUNTS ON FARM B.
  3. Create a new webapp
  4. Dismount the DB on of this new webapp using Powershell  Dismount-SPContentDatabase. 
  5. Mount the restored DB using powershell  Mount-SPContentDatabase “MyDatabase” -DatabaseServer “MyServer” -WebApplication http://sitename

Now You should be able to open the webapp on FarmB.

You can also create the new webapp on Farm B using the restored DB instead of new DB but I have seen issues some times with this process. So I would like to create new site and then mount the existing DB.

Permissions of service accounts is the KEY here. As the DB was built on a different farm with a different account it will still look for that account during the initialization. One way to move all the service accounts which are on the sql server is below

On SSMS click View->object explorer details.  Now click on security->logins which will display all the logins on object explorer details window. Select all the logins here->right click and script to new query window. You can run this query on Farm B SQL server to duplicate the accounts. Again do not forget to verify any local admin permissions if has on Farm A and replicate it on Farm B.

Cannot Delete SP WebApp

Getting right the first time is the Key for successful SharePoint implementation. Now when I say first time I am talking about production environment implementation. You practice on a sandbox, make all mistakes you can, get the steps right eventually and then implement on production. If not, then sometimes simple things like adding a webapp or deleting a  webapp can cause issues. For instance, orphaned webapp issue which might occur while you are deleting a webapp using

Remove-SPWebApplication -Identity http://webapp -Confirm

Below is the error

Remove-SPWebApplication : An object in the SharePoint administrative framework, “SPWebApplication Name=WebappTest”, could not be deleted because other objects depend on it. Update all of these dependants to point to null or different objects and
retry this operation. The dependant objects are as follows:
At line:1 char:1
+ Remove-SPWebApplication -Identity https://portalsb -Confirm
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidData: (Microsoft.Share…PWebApplication:SPCmdletRemoveSPWebApplication) [Remove-SPWebApplication], InvalidOperationException
+ FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletRemoveSPWebApplication

Error is self explanatory but you would think ,,yes of course there are objects associated with this webapp because they are part of the webapp itself and are created during the creation of webapp or adding stuff to the webapp and Remove-SPWebApplication should identify all the ties to the webapp and delete it. The answer is yes ideally Remove-SPWebApplication should take care it but situation here is that of orphaned objects or orphaned web app. Adding and deleting content DB’s or  removing webapp doesn’t go right first time or for some other reason  you are here  facing this error then below steps might help you.

  1. Identify webAPP ID by  select * from Objects (nolock) where Name like ‘%Webappname%’ . Run this against config DB
  2. Use this WebAppID you got from step #1 and run select * from SiteMap (nolock) where ApplicationId = ‘WebAPPID’ . Run this against config DB
  3. Delete Content Database ID from Configuration database, using following command STSADM -O deleteconfigurationobject -id <DatabaseID from previous query> . You can use powershell to run this.
  4. Now delete the application using Remove-SPWebApplication -Identity http://webapp -Confirm

WARNING: Messing with SharePoint databases is not supported by Microsoft and might negatively effect warranties and stuff . Its a BIG no no from Microsoft support. So do not use this method on production environment but contact Microsoft support