Month: February 2013

New Button Order ‘Bug’ and Document Sets

The Quirk

Using the SharePoint GUI to modify list or library settings with the goal of changing the ‘new button order’ or ‘default content type’ may yield unexpected results.

Under List Settings, this is the functionality in question
Under List Settings, this is the functionality in question

Confusingly (or perhaps to avoid confusion) the control which displays the ordering of the content types for the New button, along with their visibility, does not show the items in the order in which they have been set.

Initial view of the New button order control
Initial view of the New button order control

As an example of this, I will set a content type marked as not-visible to have an order of 1.

I have am marking a non-visible content type as the default content type (position 1)
I have am marking a non-visible content type as the default content type (position 1)

I press OK to save the form. Upon returning to the form it would be reasonable to expect to see the control rendered with the non-visible content type in position 1 as we have just set it to be this way.

I would have expected the control to render like this. IT DOES NOT!
I would have expected the control to render like this. IT DOES NOT!

However, this is not the case. You will see the content types listed in same order as before the change was made.

After making the change, the control is rendered in exactly the same way as it was before the change
After making the change, the control is rendered in exactly the same way as it was before the change

The control always displays the visible content types at the top of the list which are then sorted by order number. The content types which are not marked as visible are then shown in alphabetical order. Importantly, this is just how they are displayed. The actual content type order may be different depending on how you have set it.

So who cares?

Most likely there are very few people who will even notice this let alone care. In fact, in nearly all scenarios it makes perfect sense to render the control this way. That is, until you want to have a default content type that is not visible under the new button. At this point the control may become very misleading. There is really just one case where the control does not accurately display the functional impact of changing the content type order. When you set a non-visible content type as the default content type (position 1), it is still treated as the default content type, despite how the control may render it.

Why would you want a default content type that is not visible under the new button?

In my case it was because in the library’s root folder only document set content types and a particular document content type (A) were allowed. However, inside the document set only a different document content type was allowed (B). By setting the document set’s allowed content type you can have the new button display content types that are not listed as visible in the list settings. All good, you can only create documents of content type B inside the document set and only create document of content type A outside the document set.

My issue arose when a user uploaded a document to the document set. An uploaded document ignores the document set’s allowed content type and is created as the first content type listed on the New button order in the list settings. To workaround this issue I set content type B as position 1, which works as expected despite how the control may render it.

ULS Log Analyser

Infrastructure contacted me to complain that one of our SharePoint environments was logging too much data (via the ULS) and it was becoming unmanageable (an Operations Management tool like SCOM has not been configured). Looking through many gigabytes of text, even with a free tool like ULSViewer, it is difficult to be confident that you are correctly identifying the most common issues, it is an inaccurate art at best.

That is why I wrote a log analyser as a PowerShell script which will process ULS log files and, using fuzzy comparison, create a report of the most frequently occurring log entries.

I am very well aware that this is not necessarily useful information in many cases (hence I had to write this script myself). Nevertheless I found it useful in my scenario and I hope that some of you may as well.

Just in case you are interested: using this script I was able to declare with certainty that logging by the SPMonitoredScope class made up almost 30% of total log entries. This will be reduced by explicitly stating the log severity in the class constructor as verbose and maintaining a log level of  Medium for the SharePoint Foundation : Monitoring diagnostic logging category.

A few things of note:

  • You may want to add to or remove from the set of replace statements in order to increase/decrease the ‘fuzziness’ of the comparison. Adding a replace statement for removing URLs may be a good candidate if you wish to increase matches.
  • The script loads entire files into memory at once. Be aware of this if you have very large log files or not much RAM.
  • The output file is a CSV, open it with Excel.
  • By default the script will identify and analyse all *.log files in the current directory.
  • If you cancel the script during processing (ctrl+c) it will still write all processed data up until the point at which it was cancelled.

I quite enjoy PowerShell-ing so expect to see more utilities in the future.

SharePoint Maintenance Mode Automation with PowerShell

In an ideal world, downtime (scheduled or otherwise) would be avoided entirely. Unfortunately, there are plenty of reasons why a web site may need to go into a scheduled maintenance mode. It’s important that this is done correctly and performing such as task across a farm manually can be error prone and tedious.

 

Maintenance

In my case, I wanted to automate the activation/deactivation of a maintenance page across a SharePoint farm with multiple Web Front End servers. The same script would be run across a number of different environments with differing topology depending on requirements (development, QA, staging, production, etc).

 

As of .NET 2.0 a very useful feature was introduced which makes putting a single web application (on a single server) into maintenance mode straightforward. If you drop a file named “app_offline.htm” into the IIS web application directory for your web site it will “shut-down the application, unload the application domain from the server, and stop processing any new incoming requests for that application. ASP.NET will also then respond to all requests for dynamic pages in the application by sending back the content of the app_offline.htm file”. [quoted from ScottGu’s Blog].

 

Leveraging this technique I have written a script to provision (or remove) a maintenance page correctly across all the required servers in a SharePoint farm.

 

A few things of note:

  • There are a number of SharePoint specific PowerShell commands being used so, as it is, this script cannot be used for other, non SharePoint, ASP.NET web sites. I would like to hear from anyone who modifies it for another use.
  • The user running the script will need to have enabled PowerShell remoting (Enable-PSRemoting -Force) as well as permission to Write and Delete from the file system of the other servers.
  • As it is, the script drops the app_offline.htm file for every web application zone. In my case, I only wanted to block users from accessing the zone configured to use our custom claims provider. I have left in the check for this in case you find yourself in a similar situation.
  • The maintenance page must be entirely self-contained. By this I mean that all CSS and JS must be embedded and even images must referenced using inline base64 representations. See here for an easy way to achieve this.
  • If want to perform an IISRESET and stop/start the  SharePoint Timer Service at each WFE before taking down the maintenance page then uncomment the relevant lines.

If you find this helpful please subscribe to our feed and feel free to leave a comment with your thoughts.