Wednesday, February 29, 2012

How SharePoint Deals With Time And Time Zones

What’s Going On Here?

It’s a little weird how hard it is to find some detailed descriptions on how SharePoint handles time, and time zones. So here’s a dump on a lot of things time and time zone related to better help you troubleshoot and predict behavior.TimeWarp

How Time Is Stored

Fields like created/modified are stored will all other list item properties in the dbo.AllUserData table as tp_Modified and tp_Created. Like all list items, events are stored in this table as well.

Time Calculation With Respect to Time Zones

Time gets stored using the clock of the machine, this is not influenced by the time zone of the machine. If the clock on the server is off, the time stored is off by the amount of the clock skew. Changing the time zone of the server (OS) doesn’t affect how time is stored. This is true for most applications.


If a server is at 6pm PST (Pacific) and you change the time zone to EST (Eastern) sure the time looks like it changes from 6pm PST to 9pm EST, but those times are equivalent. 9pm EST is just another way of writing 6pm PST. Events taking place in California are really happening at the exact same time in New York, their citizens just happen to format time differently. Time zones are just another way of expressing (formatting) the current time. To be clear. There is only one time, there are many time formats…and there is no spoon.

The Clock IS Important Though

If you change the time on the server (OS) clock you’ll change how time will get stored (for new edits/additions). In this case you’ve actually had an impact on time. Namely because going from 6pm PST to 7pm PST means someone actually lost an hour they’ll never get back (not that fake ones you tell yourself about when you travel through different time zones). By changing the clock from 6pm PST to 7pm PST, you’ve effectively moved the server through time. As a result, this will effect the times that items are recorded to be stored at.

How Time Zones Get Set

By default all your users see the time as it is formatted at the root site (SPWeb) level. These settings get set when the site collection is provisioned by the web application default time zone (Figure 1 shown below). These settings get copied down when new sub sites are provisioned under the root site. Finally, if any user doesn’t like the way dates and times are displayed, they can override how time is presented to them using their personal regional settings (Figure 2 also below). But most of the time its the root site settings time zone that users are complaining about.

Default Site (SPWeb) Time Zones

This setting dictates the formatting/time zone for all data in the site. By default these get copied down from the parent web at time of creation. You can view/change these settings (if you’re a Site Administrator) by going to:
  1. Site Actions->Site Settings
  2. Click on Regional Settings
Site (SPWeb) Regional Settings including Time Zone
Figure 1. Site (SPWeb) Regional Settings
This setting is dictating how time is displayed to all users whom haven’t expressed a preference using their personal regional settings. At the root of the site collection (root site), you can also tell all sub sites to inherit the settings of the root web, resetting them to a single time zone.
Changing the Regional Settings time zone for a web programmatically looks like the code below. Time zone IDs come from a list of known time zones.

using (SPSite siteCollection = new SPSite("http://localhost"))
    using(SPWeb websiteRoot = siteCollection.RootWeb)
        SPRegionalSettings regionalSettings = websiteRoot.RegionalSettings; 
        SPTimeZone timeZoneIndianaEast = regionalSettings.TimeZones[15]; 
        regionalSettings.TimeZone.ID = timeZoneIndianaEast.ID; 

User Site Collection Time Zones

We say user site collection time zones settings because even though this is stored per user, these settings reset in across site collections. Just because you’ve set this in site collection A doesn’t have any impact on site collection B. It will follow you around across many sites (SPWeb) within a site collection though.

You can override the default site time zone by going to:

  1. Click on your username in the header and click on My Settings.Click on My Settings to access Regional Settings
  2. Click on My Regional Settings.
  3. Uncheck Always follow web settings and override the time zone with one of your preference for this site collection.
User Site Collection Time Zone settings overriding the default time zone.

Figure 2. User Site Collection Time Zone settings  
overriding the default time zone

After you click OK, time will be formatted for the time zone you dictate.
You can change this for a given user with the following code:

//Create a new regional settings based off of the current web.
SPRegionalSettings regionalSettings = new SPRegionalSettings(web, true);

//Set some settings
SPTimeZone timeZoneIndiaEast = regionalSettings.TimeZones[15];
regionalSettings.TimeZone.ID = timeZoneIndiaEast.ID;

//Assign to user and update.
user.RegionalSettings = regionalSettings;


There are some interesting effects of the time zone settings. For instance, if you ship a site collection to another time zone, it will still behave as if it’s in your original time zone with no difference at all so long as the clock at the host is the correct time.

Different users can have very different time settings across different site collections. The good news is that they get the final say on how time is formatted.

Both these settings can be manipulated programmatically. When these settings are set appropriately they can help users from very different time zones collaborate on data with time formatted in a way that make sense to them. This especially applies to event/calendar items.

Hope that helps someone, regional settings can have a big impact on collaboration projects.

My Best,

Sunday, February 12, 2012

Troubleshooting The Windows SMTP Server

Why Isn’t My E-mail Getting There?

Email is a very common but hard feature to troubleshoot.
No one gets a hi-five for implementing an email feature. I’ve tried it before, it’s impressively devoid of gratitude.
Email is one of those features that’s just supposed to work and very little thought is often given to how difficult it really is to get right. Even if users didn’t expect it to be instantaneous and scale to legendary sizes, they definitely wouldn’t hand out accolades for all the troubleshooting that email brings to your door.
Email is as complicated as ever, and requires a ton of different systems to be in sync just for a single message to get through. Components like:
  • Application Settings
  • SMTP Server auth/relay settings
  • DNS (appropriate MX, A, and potentially PTR and SPF) both internally and externally
  • Email client and Server server spam filtering (text processing, attachment blocking, black listing, etc…)
…just to name a few, often present issues and ensuring their correct often crosses multiple disciplines and sometimes organizations. The broad domain of knowledge required to diagnose email issues can often cause their troubleshoots to be prolonged.


Fortunately most troubleshoots usually fall into one of three categories:
  1. Application/SMTP Server Issues – These are problems between the application and the SMTP server, usually there’s a stack trace or some kind of very visible error code thrown for the application or in the Event Viewer/SMTP Log files. These are for things like:
    • Unable to authenticate
    • Unable to relay
    • Email is invalid (one of its fields breaks the RFC)
    • etc…there’s a bunch of them, but they they’re usually pretty easy to troubleshoot.
  2. Sending SMTP/The Internet/Destination SMTP – This is where things get a little bananas. A lot of SMTP server’s aren’t great at logging (ahem, all versions of IIS to date), and it’s hard to get feedback on where in all things are going sideways.
This is also where a lot of developers start to feel out of their element. Checking DNS records and relating them to email behavior has traditionally been reserved as a core IT task. This is where tools like SMTPDiag save the day. Weighing in at 79 KB this tool can be a life savor that stops you from needing to memorize telnet “ehlo” commands and other awkward SMTP command syntax.
SMTP Diag runs a variety of tests, like DNS lookups and then goes through the motions of sending (doesn’t actually send) an email for every server that has an MX record. This usually tests:
  • DNS – Both sending and receiving domains have MX records, have A records.
  • Reachability – Both the sending and receiving domains’ email servers are accessible.
  • Accessible - Connects to SMTP servers and goes through the motions of sending an email from/to the given addresses.
Here’s an example of it running in verbose mode:
SmtpDiag.exe “” “” /v
Just today the utility helped me realize that some emails stuck in my Windows 2008 SMTP server queue were really stuck there not because my SMTP server was set up incorrectly, but because my ISP was stopping outgoing port 25 traffic. My only regret is not running the thing earlier in my troubleshoot (I started at my application and SMTP server).
3. Assuming both of the above check out, then you most likely have something on the user’s email client or on the destination email server (read spam filtering). Which also means it’s officially not your fault.
I hope the above helps someone, these troubleshoots can often be a nightmare and there’s nothing like a good tool to help you wake up.
Good Luck,