SharePoint ULS Logging Permissions Required (Not Logging)


Is your custom ULS logging not appearing in the SharePoint ULS logs?

I have had the (sometimes torturous) pleasure of developing custom SharePoint solutions for a number of years now and one of the issues I encounter from time to time is when my custom ULS logging is not being written to the standard SharePoint ULS logs. I usually encounter this when most other developers don’t. This is primarily because I always build out my SharePoint development environments using several service accounts in an effort to replicate the target production environment as much as possible. Doing this allows me to catch and reproduce security related design and coding issues that would otherwise go undetected in my development environment, but are most certainly exposed in QA or Production. This logging issue (entries missing) is likely to occur when using a web application pool service account that differs from the farm account. This is simply a best practice that all developers should follow, but many don’t out of laziness.

So, to successfully log to the SharePoint ULS logs the application pool service account must be in the Performance Log Users group in Active Directory. This group is located in the Builtin folder in Active Directory Users and Computers. Any SharePoint service account that executes your custom logging will need this access.


SharePoint Cumulative Updates Best Practices

SharePoint Cumulative Updates Best Practices

This guidance pertains to production SharePoint environments and is applicable to SharePoint 2007, 2010, 2013, and likely future versions.

Maintaining a healthy SharePoint environment requires a practical approach to applying cumulative updates. SharePoint Cumulative Updates are patches released by Microsoft that fix known issues. As their name suggest, they are cumulative in content so they include previously released patches. However, a plan that simply applies the latest updates is likely not in your best interest and can actually put your environment at risk.

General rule

Install updates and patches when you encounter an issue that is addressed by the update. The only exception is you should maintain a reasonably current level of updates. It is not ideal to let your environment lapse two years behind in SharePoint updates.

Maintain a 6+ month lag

Maintain your production environment at a 6 to 12 month update lag. In other words, don’t install any updates that are less than 6 months old, unless it is necessary. I recommend not extending much beyond a 12 month lag behind the latest updates. This keeps your SharePoint environment relatively current while minimizing your risk as new updates are applied. Should you encounter an issue after applying an update, the likelihood of a fix already existing in a subsequent update is much greater than if you had applied the newest update available. Microsoft does a good job of testing their releases, but the number of possible configurations, feature combinations, and server patch levels are almost infinite so you are wise to stay away from the bleeding edge.

Test your updates first

Every update should be applied to a test environment and thoroughly tested before applying said update to production. The idea of having to completely regression test SharePoint is not practical nor should it be expected. But you should have a test environment for every production environment, and that test environment should be used to test updates.

Urgent updates (updates that address an urgent problem in production), will require more focused and targeted testing. This is less than ideal, but necessary when a critical issue is identified. However, general operational maintenance updates can be applied to the test environment and remain there for several months before applying that same update to production. This allows for more exhaustive user and operational testing activity to expose any possible problems.

Synergy with developers

If you have SharePoint developers on staff or contract, they can provide a tremendous benefit regarding updates. You should coordinate your update plans with them to ensure they are developing with at least the current production version, or even better, the next cumulative update identified and targeted for production. I suggest developers keep their environments to a relatively recent update level. This is usually not an issue for them and can be very easy if they develop using virtual machines.

Ensuring a successful update

Below are a few points that will help you make the update process as smooth as possible:

  • Something to consider: Minimize server downtime. Placing the content databases in a read-only mode while installing the binaries right before applying the patches can reduce server downtime. This allows your users access the SharePoint servers during the initial upgrade process and only experience downtime during the later portion of the update process. Again, not necessarily a recommendation, but something to consider.
  • If you are using virtualization, take snapshots or backups of your Web Front End and Application servers(s). I am a big proponent of virtualized SharePoint servers.
  • After installing the binaries of the Service Pack, run the Psconfig command on every server:
  • psconfig –cmd upgrade –inplace b2b –wait


SharePoint 2013 Updates site

Starting the SharePoint 2013 User Profile Synchronization Service

Below are the steps to start the SharePoint 2013 User Profile Synchronization Service.

Local Administrator

Ensure the service account is a member of the local machine Administrators group.

Grant “Replicating Directory Changes” permission

Using the Active Directory Users and Computers manager, grant “Replicating Directory Changes” permission to the service account (SP_Farm).

Restart the SharePoint Timer Service

Start the SharePoint Server Synchronization Service

The service can take several minutes to start.

Dell M4600 Performance Improvement (Disable Intel SpeedStep)

Last weekend I spent a little time working at home and I could not get over how much slower my notebook was performing. I unplugged the power adaptor (130w) to run on battery alone and my performance was back. Could this be right?! So, I downloaded a free benchmarking tool and ran a few tests. The performance running on battery alone was more than double than when using the 130 watt power adaptor.

I then began spelunking around in the BIOS to see what havoc I could bring to life. There was one setting I found to be very interesting: Intel SpeedStep. The Intel SpeedStep setting was enabled, which at first glance sounds good like enabling a turbo charger for your computer. However, disabling this setting “puts your computer in the highest performance state and prevents the Intel SpeedStep applet or native operating system driver from adjusting the processor’s performance”. Here are the results of my benchmark testing. I think most people will prefer to disable this “feature”.

Dell M4600 Performance Rating

Power Source SpeedStep On SpeedStep Off Battery Charges




Medium Adaptor (130w)



No charge, No drain
(charges when off or sleeping)

Large Adaptor (180w)




The most obvious results show that using a power supply with less than 180 watts with SpeedStep enabled cuts the performance about 53% to a rating of 289 – that is a huge drop. With SpeedStep disabled and using the 130 watt power supply, not only does the performance resume to 100% generating a performance rating of 624; the battery does not drain at all. It doesn’t charge either, but it does charge when the computer is in a sleep state or powered off; which will likely not be an issue for most people.

One thing also worth pointing out is the best performance numbers were obtained when using the 180w power adaptor with SpeedStep enabled. It is my belief that this highest rating is only sustainable for short periods of time and does represent a sustainable performance rating.

I have chosen to disable SpeedStep. Disabling the Intel SpeedStep may not be ideal for those of you who spend a significant amount of time working unplugged (on battery); however, I was able to use my computer for 4 hours this weekend on battery alone with SpeedStep disabled. Most people using a Dell M4600 are using it as a portable workstation and will usually be plugged into a power source.

There is one benefit I can think of in keeping the Intel SpeedStep enabled. If you are using a lower wattage power adaptor (e.g., 180w), it will reduce your processor performance enough to allow the lower wattage power adaptors to charge your battery while using your computer. But that is about the only advantage I can think of.

Changing the SpeedStep setting (Dell Precision M4600):

  1. Reboot computer and enter BIOS by pressing F12 (on the notebook keyboard)
  2. Select BIOS Setup
  3. Performance > Intel SpeedStep
  4. Un-check the Enable Intel SpeedStep
  5. Click Apply and exit BIOS.

The tool I used for benchmarking is NavaBench.

Below is additional information about the power adaptors I use for the M4600. I needed to look this up to confirm the wattage on the power adaptors. Power P in watts (W) is equal to the current I in amps (A), times the voltage V in volts (V):

P(W) = I(A) × V(V)

Dell Power Adaptors:

Power Adaptor Model Amps x Volts = Watts
Large (180w) DA180PM111 9.23 19.5 180
Medium (130w) DA130PE1-00 6.7 19.5 130

How to correct: The security validation for this page is invalid (FormDigest)

How to correct the security error on a custom SharePoint web page:
The security validation for this page is invalid. Click Back in your Web browser, refresh the page, and try your operation again.

Short Answer:

Use SPUtility.ValidateFormDigest() and do not use AllowUnsafeUpdates.

A Less Desirable Solution (but more commonly used)

One way to get around this issue is to set the web’s (SPWeb) AllowUnsafeUpdates property to true. This is not ideal, especially when there is a more secure option.

A Better Solution

This method configures the web page to properly cache and revalidate the necessary credentials preventing the “security validation” error noted above. And, there is no need to set the AllowUnsafeUpdate spweb property to true.
Coding Steps:
Register the SharePoint web controls assembly in your aspx. Place this at the top of the .aspx file:
<%@ Register TagPrefix="SharePoint"
Assembly="Microsoft.SharePoint, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
Place the FormDigest control on the .aspx page (I place it near the end of the page):
<SharePointWebControls:formdigest id="FormDigest1" runat="server" />
In your page code-behind, call the ValidateFormDigest() method during the page OnInit() event to revalidate the page security. It is important to call the ValidateFormDigest method as early as possible in the page cycle.
using Microsoft.SharePoint.Utilities
protected override void OnInit(EventArgs&nbsp;e)
	if (Page.IsPostBack)
That’s it. Your custom SharePoint page should now successfully pass the security validation. It is also important to remember that you will need to also add the FormDigest control and call the ValidateFormDigest method in any custom user controls that are performing updates to SharePoint data.


SharePoint Feature Activation Extension Methods

Extend your SharePoint Features collection with an IsActivated, EnsureActivated, and EnsureDeactivated methods. These extensions will be available for activating or deactivating features for a Web, Site Collection, Web Application, and Farm.

public static class SPFeatureCollectionExtensions
  public static bool IsActivated(this SPFeatureCollection features, Guid featureId)
    return features.Cast<SPFeature>().FirstOrDefault(f => f.DefinitionId.Equals(featureId)) != null;
  public static bool IsActivated(this SPFeatureCollection features, string featureId)
    return IsActivated(features, new Guid(featureId));
  public static void EnsureActivated(this SPFeatureCollection features, Guid featureId)
    if (!IsActivated(features, featureId))
  public static void EnsureActivated(this SPFeatureCollection features, string featureId)
    EnsureActivated(features, new Guid(featureId));
  public static void EnsureDeactivated(this SPFeatureCollection features, Guid featureId)
    if (IsActivated(features, featureId))
public static void EnsureDeactivated(this SPFeatureCollection features, string featureId)
    EnsureDeactivated(features, new Guid(featureId));

Usage Examples:


Create Custom SharePoint Web Service WSDL and Disco ASPX Files Automatically

I just completed a SharePoint developer tool called SPDev.exe. The initial purpose of this utility is to auto-generate the web service WSDL.aspx and Disco.aspx files needed for a custom SharePoint web service.

icon_shout Automatically generate your SharePoint disco.aspx and wsdl.aspx files in seconds!
icon_shout No need to manually copy or deploy your .asmx first!
icon_shout No manual editing!
icon_shout No Disco.exe needed!
icon_shout Automatically recycles the application pool (ensuring the newest assembly is loaded)!
icon_shout Automatically deploys the final SharePoint web service files (using the -deploy option)!
icon_shout No UI to enter data each time.  A command tool you can script for fast, consistent re-use!

After having to manually modify the disco.aspx and wsdl.aspx files by hand for the last three years, I finally found it tedious enough to create this utility.  There are other tools out there, but they require you to enter information into a Windows UI, they are not script-able, and still felt to tedious for me.  Call me lazy.  :)  Time is money.  This tool is a command line utility.  Simply execute the SPDev.exe command and your MyServiceDisco.aspx and MyServiceWsdl.aspx files are immediately ready for deployment.  SPDev also allows you to script the process.  Create a .cmd or .bat file and you’ll never have to enter any parameters again.  Another big benefit is you don’t need to use the Disco.exe utility since SPDev uses IIS and .NET instead which will always be on your development machine – since you are developing for SharePoint.  And, there are no temp files are generated (unless you want them generated).

Documentation for this utility is on my blog here:

SharePoint RunWithElevatedPrivileges Example

The following example sends an email using elevated privileges.  This will elevate the privileges to execute using the service account.

The SPSecurity.RunWithElevatedPrivileges method taks a delegate method as its argument and executes that code with the service account.

        // Your code needing elevated permissions goes here.


public void SendEmail(Email email) 
        SmtpClient mail = new SmtpClient();    MailMessage message = new MailMessage(); 
        message.From = new MailAddress(this.SenderAddress); 
        message.IsBodyHtml = email.IsHtml; 
        if (!string.IsNullOrEmpty(email.Cc))            
        if (!string.IsNullOrEmpty(email.Bcc))            
        if (!string.IsNullOrEmpty(this.ReplyToAddress))             
            message.ReplyTo = new MailAddress(this.ReplyToAddress); 
        if (!string.IsNullOrEmpty(email.Subject))            
            message.Subject = email.Subject; 
        if (!string.IsNullOrEmpty(email.Body))            
            message.Body = email.Body; 

        mail.Host = this.CentralAdminOutboundServerAddress; mail.Send(message); 

SharePoint Module tag


– The Module tag is used to deploy files ‘logically’ to SharePoint when the given

feature is activated. This means they liv in the database, not physcally on disk

in the SharePoint 12 hive.

Module Attributes:

  • Path is relative to the current web site.

  • Url – is the relative url to the web site root (blank) or to the document library (i.e. "MyLibrary").

    • URL – This is the target location for your file. Effectively, this is the relative URL that points to the list that you want your files to be placed in. The relative url to the web site.

  • Path – this is the relative location between the feature and the physical file that you want to install. So if your file is in a sub-folder of the featue called "Images" then you would place "Images" as the Path. If your file is in the root feature folder (next to your feature.xml) then the "Path" would be an empty string ("").

  • RootWebOnly – this is a boolean value. If set to true, then this will only install when activated at the top-level site collection.

File Attributes:

  • Url is relative to the web site and contains the name of the file (i.e MyPage.aspx).

How to Create a Custom List with a Custom Content Type and Views


Steps to creating a new list with custom views and a custom content type:

Why use a custom content type?

  1. Create your site columns (fields) and content type, and deploy it to your development farm.
  2. Create a new generic Custom list on any site of your choosing.  Enable content type management on the list.
  3. Remove the default Item content type from the list.
  4. Add your new custom content type to the list, it should be the default.
  5. Customize your views as needed.
  6. Use the SharePoint Solution Generator to generate a List Definition for your new list.  The resulting generated Visual Studio project will contain a folder for the list that contains several form files (DispForm.aspx, EditForm.aspx, and NewForm.aspx) and an .aspx file for each view you created such as AllItems.aspx.  You will also have a schema.xml file which contains the content type definition, the views definition, and the fields section.  Leave the Fields and Views nodes/sections alone as they contain the definitions you defined.
  7. In the schema.xml file, in the ContentTypes node you will find a ContentType node defining your custom content type.  Comment (or delete) this entire node.  We will add this content type to the list via code instead of defining its association here declaratively.

The Major Task content type is commented out here because we are going to add
it programmatically via the ListInstances feature receiver.  This allows us to
properly promote all the fields in the content type to the list and enable
content type management on the list much more easily.