Why not customize a SharePoint master page.

I came across this question a lot. Simple answer would be that there are times when you need to modify and some times you don’t have to. If you are an experienced developer and know the best practices, you can modify. If not stick with html as it is much easier to handle. Recently  on SharePoint stack exchange  I read some one asking how to modify seattle.master and whether he should modify or not. Below is the best answer.

Answer:

If you will bear with my I will first answer a question you did not ask, and then I’ll get to your actual question.

What did you modify exactly, the file on disk or on the web site (through SharePoint Designer or a mapped drive) ?

If you have modified the file on disk, you should copy your changes some place safe (for later, see next) and immediately revert to the original file. Any modification to SharePoint’s OOTB files are bound to a) cause loads of problems and b) be overwritten by future updates. By modifying the file on disk you are effectively changing the master page for each and every existing site that uses that style. Most files you see in a web site are in fact links to the file on disk until they are customized(next paragraph).

If you have modified the file in the web site (in _catalogs/masterpage), in effect you have customized the file, that is you have detached it from its source definition on disk and created a local copy that now lives in the database, only for that site.

What a customized file means is: – You will need to re-apply those changes manually to any other site where you want it as they are all independent. This includes production, future sites, etc. – All of those sites, after you have modified them directly, will have their own independent copy of the file which are not related to one another so you will not be able to make mass updates to your branding.

If you have only one site at this time, you might think you are ok. But SharePoint has a tendency to grow…

If you are doing custom branding, the bare minimum would be to make a copy of seattle.master to a custom name, and work on that. That will avoid you the interference headaches with official updates and modifications to the standard master page (which you should keep as fallback should things go wrong).

Next, you should really consider a deployment package (e.g. a file on disk). Then when you create a new site, you just set it to use that master page (manually, through feature activation, at this point it does not matter). This way, all of your sites will still use an un-customized master page, meaning they will in fact all be references to the one on disk. This makes updates much easier and is the norm in enterprise settings. The same goes for your CSS and JS files.

You could have CSS and JS files in the _layout directory but for this you really want a deployment package, never drop files there manually.

And now, to specifically answer your original question:

The difference between the .master and .html pages is not that much, but you can view .html as preceding the .master. Some master pages do not have an associated .html page, but if you upload a .html file SharePoint will automatically create a .master. The latter is the one that is used in the end, with the .html being more of a “designer file” and is easier to work with for most HTML folks (has all the markup as comments, so you have fewer chances of wrecking the final ASPX markup).

So, if you have both, work on the .html file. If you have only the .master, work on that one. What you should avoid is uploading a .html file, then working on both the .master and .html files because every time you save the .html SharePoint will overwrite your .master. Once the .master is generated the .html is mostly ignored by the system.

Ref

Post

Advertisements

SharePoint List Title column

I was working on a SharePoint list and had to create few custom columns. There is no way I could use the default “Title” column. I realized that even if I hide it use a list view it will still show up when I create a new item.  There is another way to achieve this

Go to List Settings ->Advanced settings and select “Yes”  to “Allow management of content types”

Go back to list settings and you should be able to see available content types. The list should be displayed there. Click on it.

List1

Now should be in “List content types “screen where you can see different content types available by default. Select “Item” and select “Hidden”

List1

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.