Todd's Blog

On Twitter Now

Toddca — Sat, 02 May 2009 18:17:00 GMT

After being push and prodded by my friends I have decided to join the Twitter community @Toddca. I am still a bit confused on how to follow a thread/conversation but I am sure that is just me. :-)

Now lets see how dumb I can make myself look in 140 characters or less!

SharePoint Session State; The Guest That Just Won’t Leave

Toddca — Wed, 18 Mar 2009 04:01:41 GMT

MOSS uses ASP.Net session state for Forms Services, Project Server, etc. SharePoint installs a PartitionResolver which redirects the ASP.NET session state module to look to the SSP DB for its stored procedures and tables for storage of session state. Within CA there is an option to turn off Session State (its on by default) however if you try to start an OOTB workflow we attempt to load an InfoPath form via forms services and you will get probably one of the most clear and understandable errors in SharePoint (I won’t spoil the surprise here, you will either have to try it out or trust me :-)) ASP.net session state is a binary serialized representation of the client’s session state along with metadata such as the expiry and created date/time. When session state enabled sessions are inserted into the table ASPStateTempSessions within the SSP DB for each SSP.

So what’s the problem? ASP.Net Session state uses a sliding expiry which by default should expire the session state object after 60 min of not hearing from the client for which the session was created. So while this all works fine the issue is that SharePoint never cleans up these session state records out of the ASPStateTempSessions table. The result is your SSP DB(s) may continue to grow in size.

The Fix

Fortunately the fix is trivial however does involve a few manual steps which I will outline here. The goal is to create a SQL Agent timer job which will run once a minute and clean up expired sessions by executing the stored procedure ‘DeleteExpiredSessions’

1. Ensure the SQL Server Agent (SQLSERVERAGENT) service is started and set to startup when the machine starts. At a minimum this service needs to run on all SQL servers/instances which host an SSP DB.

2. Change to the .net Framework directory where ASP.Net is located, eg %windir%\Microsoft.Net\Framework[64]\v2.0.50727.

3. From the framework director run the following command replacing [YOUR SSP DB NAME] with the name of your SSP DB: aspnet_regsql -sstype c –d [YOUR SSP DB NAME] -sqlexportonly fix.sql –ssadd

4. The command from step 3 instructs the aspnet_regsql utility to generate a sql script named ‘fix.sql’ which can be used to install the ASP.Net session state stored procedures, tables, and jobs. Since everything we need for ASP.net session state is already in the SSP DB and we don’t want to edit that DB directly or risk entering into the land of “Unsupported” we only need to execute a portion of this file. Open fix.sql into SQL management studio and locate the line which has the following text: /* Create the job to delete expired sessions */ Highlight everything below this line to the end of the file. With this text highlighted execute the query (hit F5).

5. At this point you should be able to navigate to the SQL Agent service and see the job: [YOUR SSP DB NAME]_Job_DeleteExpiredSessions. As I mentioned previously this job will execute every one min and clean up expired sessions.

6. Repeat for each additional SSPs in the farm.

Run (As Your AppPool Account) Forrest

Toddca — Thu, 12 Feb 2009 06:58:37 GMT

When running within a website that uses impersonation you find it necessary sometimes to have your code stop impersonating for a period of time while you run some code. For example if you need to get off the box (not using Kerberos) and connect to another resource you will need to fall back and run as the AppPool account or logon another user and use those credentials to hit the remote resource. For the former I have written a small utility class that makes this possible. There are other samples out there however some use PINVOKE and I wanted something really simple and easy to use.

To use the code you will do something like:

using (new AppPoolImpersonator())

{

//unimpresonated code here

}

The class looks like so:

public class AppPoolImpersonator : IDisposable

{

WindowsImpersonationContext _windowsImpersonationContext;

public AppPoolImpersonator()

{

if (_windowsImpersonationContext == null &&

!WindowsIdentity.GetCurrent().IsSystem)

{

_windowsImpersonationContext = WindowsIdentity.Impersonate(System.IntPtr.Zero);

}

public void Dispose()

{

Undo();

GC.SuppressFinalize(this);

}

public void Undo()

{

if (_windowsImpersonationContext != null)

{

_windowsImpersonationContext.Undo();

_windowsImpersonationContext = null;

}

PrepareToMove Away From Running This Command

Toddca — Fri, 30 Jan 2009 18:07:00 GMT

If you are a SharePoint Admin that is still running stsadm –o PrepareToMove before detaching a content DB AND your farm is running at least the Infrastructure Update (IU) then stop! Stop running the command, its not necessary and it is causing you problems and you probably don't even realize it.

If prepareToMove is run within a SharePoint farm that has at least the IU that Content DB will no longer participlate in profile syncronization; even if you remove and reattach the content DB to the same farm. The issue is due to a change in behavior that we introduced in the Infrastructure Update (IU). Before the IU when a content DB was removed and reintroduced back into a SharePoint farm the DB ID would change/regenerate. This had the side effect of causing all content within those DBs to undergo a Full Crawl by search. As you can imagine this a huge overheard so in the IU we ensured that the Content DBs never had to change IDs when reintroduced into a Farm. The PrepareToRemove was originally needed to ensure we did not have to redo a full sync when the same content DB with a new ID was reintroduced. Since this ID now does not change this is no longer needed when running within a farm that has at least the IU installed.

PrepareToMove sets 'Moving' to True in the SiteSynch table of the SSP DB which signals to the profile sync job to ignore the DB which has the effect of not allowing profile syncs to occur for this DB. After attaching a Content DB back into the IU farm 'Moving' is still set to True. Even after the sync timer job fires and the stored procedure profilesynch_RegisterSiteToSynch is executed this content DB will still have its 'Moving' set to True.

The fix/resolution is to run PrepareToMove again (ok so I lied there is a case where you want to run it with the IU) but this time with the –undo option. The -undo command is harmless and it will set 'Moving' back to False and allow profile syncs to this content DB to start running again.

Be on the lookout for new TechNet and KB guidance around this command.

High Memory is Relative

Toddca — Sat, 24 Jan 2009 04:42:00 GMT

Like most folks I customize my computer to fit my needs. I apply a myriad of registry settings, applications, utilities, and adjustments to my machine to get the environment just the way I like. One item I always seem to change is the buffer height of my command prompt. I find it is useful to increase this buffer when I am running commands that have a ton of output or when I am debugging an application with a command line debugger. Rather than have the text just flow off the buffer I typically increase te Height buffer to the max, 9999. When doing so you may run across one of the most useless messages you may come across in Windows.

WARNING: Screen buffer size will require 1 MB of memory per window.

Obviously the guy or gal that wrote this message has not looked at the memory consumption of Outlook 2007.:-) The message actually goes way back. I remember filing a bug, which was subsequently rejected, on this dialog when Windows 2000 was still in Beta. As far as I can tell it is a holdover from the days when the premier operating system around was known simply as NT. As best as I can figure it was put into the OS around the NT 3.x days however if anyone is still running those version and can confirm or deny I would love to know. But here it is in Windows Vista still alive and kickin.

Customizing the Rendering of a Custom SPField

Toddca — Fri, 23 Jan 2009 23:37:00 GMT

I was recently asked by a customer how to use a PropertySchema field value within a RenderPatten's CAML to control how a field is rendered. The idea is to create a new instance of the field and have some method to control how that field will be rendered at the time the column is instantiated. Unfortunately field values from the PropertySchema are not available via a <Property Select='myValue'/> within a ReanderPattern's CAML and nor is it possible to call a custom getter off the SPField derived class of your custom SPField. In most cases when a field is rendered it is done so within native (non-managed) code so the getter on your .net assembly will not get called. The field schema stored in the DB is what gets read to help generate the rendered output. Fortunately this schema can be accessed by SPFIeld.SchemaXml. Adding properties or attributes to the root element of this XML will allow the RenderPattern CAML access.

So let's take a look at a sample. For my scenario I want URL field however I want to control how that field is rendered. By default a URL field just renders the URL without wrapping that URL in an <a> tag. In our example we want to create a true hyperlink so we are going to generate a RenderingPattern which will wrap an <a> tag around the field value. In addition we want the creator of the field to choose what happens when that link is selected by the user. That is, will the navigation happen within the same window or will the browser open the URL in a new window. I call these options "Self" and "New" respectively.

Now that we have our scenario let's take a look at what it will take to wire up the new field. First I need to define our field via fldTypes XML. Code 1 shows what this looks like. As you can see the Parent is "URL" because we want to use the same storage and rendering of the built-in URL however we are going to tweak it a bit. The FieldTypeClass will be outlined in Code 2. The PropertySchema field is used to collect the user's intent on how the URL will behave within the client's browser and finally we have RenderingPattern CAML which will control how the field will be rendered within the browser. Note I have a FieldSwitch on a Property called 'HowOpenUrl', this value will not be chosen from the PropertySchema's HowOpenUrl directly however once you take a look at Code 2 you will see how this is done. The reminder of the RenderPattern uses the FieldSwitch to determine how to render the URL. The default rendering is an <a> tag with the target set to _self so the URL will be navigated to within the same window.

Code 1 – fldtypes_sample.xml

<?xml version="1.0" encoding="utf-8" ?>

<Field Name="TypeName">ConfigurableURL</Field>

<Field Name="TypeDisplayName">Configurable URL</Field>

<Field Name="TypeShortDescription">Configurable URL</Field>

<Field Name="FieldTypeClass">SampleConfigurableField.ConfigurableUrlField, SampleConfigurableField, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3de2414d286dff3d</Field>

</Field>

</Fields>

</PropertySchema>

<Expr>

</Expr>

</Case>

</Case>

</Default>

</FieldSwitch>

</RenderPattern>

</FieldType>

</FieldTypes>

After creating a Class Library project and adding the proper reference to Microsoft.SharePoint I added the following code to define my ConfigurableUrlField. This field derives from the SPFieldURL class which is important because we defined in Code 1 that our ParentType is "URL". Like all custom fields we need to create the two proper constructors which not only allow our type to be constructed but properly instantiates the base type. Next we need to override the OnAdded() and OnUpdated() methods which each get called whenever this field definition is added to a new site column or when the site column definition is updated, for example when someone wants to change from a rendering of this field from "Self" to "New". The magic all happens in ConfigureSchemaXml(), this is where we access the base.SchemaXml and update it with our custom property's value as configured by the user. This is the only chance we get to manipulate the schema before being stored in the DB and used to render the field. Note the name of the attribute being added/updated needs to match the name being used within the FieldSwitch: <Property Select='HowOpenUrl'/>

Code 2 – ConfigurableUrlField.cs

namespace SampleConfigurableField

{

using System;

using Microsoft.SharePoint;

using Microsoft.SharePoint.WebControls;

using System.Xml;

public class ConfigurableUrlField : SPFieldUrl

{

bool _updating = false;

public ConfigurableUrlField(SPFieldCollection fields, string fieldName)

: base(fields, fieldName) { }

public ConfigurableUrlField(SPFieldCollection fields, string typeName, string displayName)

: base(fields, typeName, displayName) { }

public override void OnUpdated()

{

//ConfigureSchemaXml() will cause the OnUpdated event to be raised,

//to keep out of a stack overflow condition we bail early when updating

if (_updating)

return;

_updating = true;

{

base.OnUpdated();

ConfigureSchemaXml();

}

_updating = false;

}

public override void OnAdded(SPAddFieldOptions op)

{

base.OnAdded(op);

ConfigureSchemaXml();

}

void ConfigureSchemaXml()

{

string howOpenUrl = (string)base.GetCustomProperty("HowOpenUrl");

howOpenUrl = AreStringsEqual("New", howOpenUrl) ? "New" : "Self";

XmlDocument doc = new XmlDocument();

doc.LoadXml(base.SchemaXml);

if (doc.FirstChild.Attributes["HowOpenUrl"] == null)

{

XmlAttribute attrib = doc.CreateAttribute("HowOpenUrl");

attrib.Value = howOpenUrl;

doc.FirstChild.Attributes.Append(attrib);

}

else

{

doc.FirstChild.Attributes["HowOpenUrl"].Value = howOpenUrl;

}

base.SchemaXml = doc.OuterXml;

}

private bool AreStringsEqual(string s1, string s2)

{

return (String.Compare(s1, s2, true) == 0);

}

public override BaseFieldControl FieldRenderingControl

{

get

{

BaseFieldControl fldControl = new UrlField();

fldControl.FieldName = InternalName;

return fldControl;

}

For completeness I have included the manifest.xml used for deployment of the solution. I will not go over that here since the concept is covered in so many other places.

Code 3 – manifest.xml

<?xml version="1.0" encoding="utf-8" ?>

<Solution xmlns="http://schemas.microsoft.com/sharepoint/"

SolutionId="733641DA-95D9-446E-812E-6070947171B2"

DeploymentServerType="WebFrontEnd"

ResetWebServer="TRUE">

</SafeControls>

</Assembly>

</Assemblies>

</TemplateFiles>

</Solution>

Once we have our solution added and deployed within our farm it is time to use the field. I created a test list and added a new column based on the Configurable URL field I just deployed. Note the open to set how the URL will open within the browser.

Now back at my list I create a new list item – note that we did not create a custom field control but rather are using the SPFieldUrl's field control for editing of this field.

Finally we can see the URL in action. Obviously an image does not do it justice but if I look at the HTML source I can find what actually got rendered:

<a target="_self" href="http://www.msn.com" href="http://www.msn.com">http://www.msn.com</a>

The Zero Downtime SharePoint Patching Myth

Toddca — Sat, 02 Aug 2008 23:47:00 GMT

Unfortunately it is not possible to update/patch SharePoint without occurring some amount downtime. So the only options available to us are to minimize downtime.

I think of downtime in two ways, 'not available' and 'reduced functionality'. The second obviously is more closely aligned to zero downtime however for a large farm it is difficult logistically to achieve. Reduced functionality is providing your users with a read only farm during the time in which the patching of the primary farm is occurring. This requires the entire primary farm to be swung to another farm with its content DBs set to read only mode. Once patching on the primary farm is complete traffic is redirected back to the primary farm.

Since we want to always keep our downtime window as small as possible we should always follow a good and well tested practice of upgrading a farm to ensure there are no surprises along the way that will impact our downtime. There are two phases of upgrade, laying down updated binaries and running psconfig. The second phase, running psconfig, is the one that is going to take the majority of the time and the time taken is directly proportional to the amount of site collections within the farm. Psconfig upgrades each content DB schema and in many installations this can take many hours to complete. We have found in our testing in many real world deployments that detaching all content DBs other than the CA content DB, running psconfig, and then attaching content DBs back can help reduce the amount of downtime needed when patching SharePoint. One myth that needs to be dispelled now; the reduction in downtime is not achieved because psconfig runs faster or gets better throughput when upgrading the Content DB.

As with most things in SharePoint there are rules around the DB Attach process:
1. Only one Content DB can be attached to a farm at any one time.
2. Once a Content DB has been attached to a farm all of its content is marked as updated and therefore will incur what is effectively a full crawl the first time search crawls this DB. More on this later.

So taking into account rule #1 there are two ways we can optimize this process to reduce downtime, 1) Prioritize, attach content DBs that belong to Web Applications that are highly sensitive to downtime first and make them available, and 2)Use surrogates, build out additional worker farms which are used as surrogates to host attaching content DBs.

The process of using surrogate farms includes building one or more single server, throw away, farms that are running the same patch level you are upgrading your primary farm to. This process has been well documented here. This approach however has downsides such as the need for additional hardware, the additional time and effort to build out these farms, and the need for your SQL server to be able to handle the additional load.

Let's take a look at the steps of a typical upgrade with DB prioritization:

0. Announce and coordinate downtime with IT, users, etc.
1. Take farm offline, typically you are pulling the WFEs out of a load balancer or for the case of reduced functionality, swinging DNS settings to another read only farm replica.
2. Detach all content DBs from the farm.
3. Run WSS and if applicable MOSS upgrade patches on each server and choosing to not run psconfig. You are only going to run psconfig once, not once for each upgrade package.
4. After all servers have been patched run psconfig on the CA machine. The execution of psconfig will not take near as long because all the content DBs are detached.
5. For each additional machine in the farm and one at a time run psconfig.
6. At this point your farm, without any content DBs, is upgraded and only the content DBs require upgrade.
7. Starting with the web application that is most critical to get back into production start attaching its content DB(s). Once complete put this Web Application back in the load balancer and notify everyone it is back online.
8.Continue running through each additional Content DB until each is attached back into the farm.

I have a tool that I will be releasing soon named CDBManager that will help with the DB prioritization method of upgrade, specifically it allows you to:

Mass DB detach all the content DBs in a farm
Reorder content DBs by priority
Automate the attaching of content DBs and provides ETA of when each DB will be complete (important because there is not a progress indicator otherwise)
Manages the upgrade.log file by creating an upgrade.log file for each content DB attached. As you may know each time a Content DB is attached to a farm and upgraded a new upgrade log is either created or if one already exists it is appended too. The problem with this approach is that all your upgrade logging is in a single file and not split out by Content DB. CDBManager renames the upgrade.log file after each Content DB has completed attaching with the name of the Content DB. This makes it much easier to go back through each log and analyze what might have gone wrong within a certain Content DB on upgrade.

I have a couple of large enterprise customers that are testing the tool now. Once we get past any breaking issues I publish the bits.

One additional point about the prioritization upgrade approach; should a content DB fail to attach along the way for whatever reason you should continue to DB Attach the remaining content DBs. While the upgrade is progressing along you now have the opportunity to investigate and mitigate the issues with the failed content DB in parallel to the upgrade and once ready retry the DB attach operation.

So time to revisit DB Attach rule #2. When a content DB is attached into a farm its ID is changed. This has the side effect of effectively marking each object within the content DB as changed. This means that when the crawler service hits this content DB, weather doing an incremental or a full crawl, it will effectively do a full crawl as it believes all the content has changed. The Infrastructure Update (IU) changes all of this and effectively takes this rule out of play. After installing the IU the Content DB is not longer changed. This means an incremental crawl after re-attaching a Content DB is really an incremental crawl. No more full crawls after detaching and attaching content DBs, yea!

The Infrastructure Update (IU) KB article also has this blurb:

Improvements to the time that is required to update and upgrade Windows SharePoint Services sites.

So what does this mean? Any fix before the IU psconfig updates each site collection in the farm by updating its build version to reflect the most recent value. After installing the IU we only hit site collections to update them if a schema object of the site collection needs to be updated, such as an update to the template schema. This type of update is far less frequently since hotfixes rarely do site collection schema updates (IU however does to support the new search features). The end result is that if a fix does not require a schema update psconfig does not go through each site collection and update the build number, so this will drastically reduce the amount of time necessary to perform the upgrade.

So there you have it, while we cannot upgrade a live farm we do have processes and available fixes that will move us closer to the nirvana of a zero downtime upgrade.

Happy upgrading!

Where Did That AppPool Go?

Toddca — Thu, 05 Jun 2008 21:36:00 GMT

I am a big fan of anything that gives me more insight as to what is happening on my system. One such IIS 6 tweak which I find is greatly overlooked is the additional AppPool logging you can get out of IIS 6. It blows me away that this was not "on" by default -- but that is another blog entry.

The tweek involves modifying the metabase per http://support.microsoft.com/kb/332088 to turn on this additional logging at the AppPool. This KB has a command:

cscript adsutil.vbs Set w3svc/AppPools/DefaultAppPool/LogEventOnRecycle 255

This turns the logging on for the DefaultAppPool however a more global approach, and one that would be useful esp. when you have more than one AppPool like us SharePoint guys is:

cscript adsutil.vbs Set w3svc/AppPools/LogEventOnRecycle 255

It goes without saying but after you set this you want to do some kind of monitoring for these events to get a since as to what is going on with your AppPools throughout the day.

Database Disconnect Issues with SharePoint

Toddca — Mon, 24 Mar 2008 04:50:00 GMT

I have spent a good deal of time lately working with one of my MOSS 2007 customers on a database disconnect issue that has been plaguing them since SPS 2003. The following blog entry are the steps I went through to track down this issue. It was not without the help of some of my co-workers that made this journey successful. I also need to mention that the customer made an incredible contribution of time and effort on this as well. In many cases most customers would have bailed and just resigned to the fact this issue would not be resolved but this one was different. They stuck it out and in the end we nailed the issue.

The diagnostic tools used during the investigation included:

ULS Logs
Netmon
ADO.Net Tracing
Netstat
DbgView
TDIMon
NT Event Log
WinDBG (Debugger)
LogParser
netdiag

This issue occurred in every single environment they had, Production, QA, Dev, POC and was prevalent in that it occurred several dozen times a day on each server. The issues presented as multiple event log entries in the event log, specifically there were many event 7888 and 6483 events littered about in the Application Event Log.Looking at the ULS logs we could confirm the same error being logged there.

What was most interesting about these events where that each where logged as a timeout expired operation and the operation being performed was an initial connection. You can tell this by looking at the various method names such as TdsParser.Connect() (on an already existing connection we would be running TdsParser.Parse), AttemptOneLogin, CreateConnection(), etc would all seem to indicate we were not using a pooled connection. The timeout message really bothered me too; I knew the connection strings being used where managed by SharePoint and typically the TIMEOUT parameter is not set in the connection string explicitly so this was probably not the result of a low TIMEOUT value being set by a rouge configuration setting.

Event Type: Error
Event Source: Office SharePoint Server
Event Category: Office Server General Event ID: 7888
Date: 9/6/2007
Time: 7:24:10 AM
User: N/A
Computer: XXX-XXXXX
Description: A runtime exception was detected. Details follow.
Message: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
Techinal Details:
System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
at System.Data.SqlClient.TdsParserStateObject.ReadSniError(TdsParserStateObject stateObj, UInt32 error)
at System.Data.SqlClient.TdsParserStateObject.ReadSni(DbAsyncResult asyncResult, TdsParserStateObject stateObj)
at System.Data.SqlClient.TdsParserStateObject.ReadPacket(Int32 bytesExpected)
at System.Data.SqlClient.TdsParser.ConsumePreLoginHandshake(Boolean encrypt, Boolean trustServerCert, Boolean& marsCapable)
at System.Data.SqlClient.TdsParser.Connect(ServerInfo serverInfo, SqlInternalConnectionTds connHandler, Boolean ignoreSniOpenTimeout, Int64 timerExpire, Boolean encrypt, Boolean trustServerCert, Boolean integratedSecurity, SqlConnection owningObject)
at System.Data.SqlClient.SqlInternalConnectionTds.AttemptOneLogin(ServerInfo serverInfo, String newPassword, Boolean ignoreSniOpenTimeout, Int64 timerExpire, SqlConnection owningObject)
at System.Data.SqlClient.SqlInternalConnectionTds.LoginNoFailover(String host, String newPassword, Boolean redirectedUserInstance, SqlConnection owningObject, SqlConnectionString connectionOptions, Int64 timerStart)
at System.Data.SqlClient.SqlInternalConnectionTds.OpenLoginEnlist(SqlConnection owningObject, SqlConnectionString connectionOptions, String newPassword, Boolean redirectedUserInstance)
at System.Data.SqlClient.SqlInternalConnectionTds..ctor(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, Object providerInfo, String newPassword, SqlConnection owningObject, Boolean redirectedUserInstance)
at System.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection)
at System.Data.ProviderBase.DbConnectionFactory.CreateNonPooledConnection(DbConnection owningConnection, DbConnectionPoolGroup poolGroup)
at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)
at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
at System.Data.SqlClient.SqlConnection.Open()
at Microsoft.Office.Server.Data.SqlSession.OpenConnection()
at Microsoft.Office.Server.Data.SqlSession.ExecuteNonQuery(SqlCommand command)
at Microsoft.Office.Server.Data.SqlDatabaseManager.HasAccess(String user)
at Microsoft.Office.Server.Administration.SharedResourceProvider.SynchronizeConfigurationDatabaseAccess(SharedComponentSecurity security)
at Microsoft.Office.Server.Administration.SharedResourceProvider.SynchronizeAccessControl(SharedComponentSecurity sharedApplicationSecurity)
at Microsoft.Office.Server.Administration.SharedResourceProvider.Microsoft.Office.Server.Administration.ISharedComponent.Synchronize()

Event Type: Error
Event Source: Office SharePoint Server
Event Category: Office Server Shared Services
Event ID: 6483
Date: 9/26/2007
Time: 6:55:10 AM
User: N/A
Computer: XXX-XXXXX
Description:
Application synchronization failed for Microsoft.Office.Server.Search.Administration.SearchService.

Reason: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.

Techinal Support Details:
System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
at System.Data.SqlClient.TdsParserStateObject.ReadSniError(TdsParserStateObject stateObj, UInt32 error)
at System.Data.SqlClient.TdsParserStateObject.ReadSni(DbAsyncResult asyncResult, TdsParserStateObject stateObj)
at System.Data.SqlClient.TdsParserStateObject.ReadPacket(Int32 bytesExpected)
at System.Data.SqlClient.TdsParser.ConsumePreLoginHandshake(Boolean encrypt, Boolean trustServerCert, Boolean& marsCapable)
at System.Data.SqlClient.TdsParser.Connect(ServerInfo serverInfo, SqlInternalConnectionTds connHandler, Boolean ignoreSniOpenTimeout, Int64 timerExpire, Boolean encrypt, Boolean trustServerCert, Boolean integratedSecurity, SqlConnection owningObject)
at System.Data.SqlClient.SqlInternalConnectionTds.AttemptOneLogin(ServerInfo serverInfo, String newPassword, Boolean ignoreSniOpenTimeout, Int64 timerExpire, SqlConnection owningObject)
at System.Data.SqlClient.SqlInternalConnectionTds.LoginNoFailover(String host, String newPassword, Boolean redirectedUserInstance, SqlConnection owningObject, SqlConnectionString connectionOptions, Int64 timerStart)
at System.Data.SqlClient.SqlInternalConnectionTds.OpenLoginEnlist(SqlConnection owningObject, SqlConnectionString connectionOptions, String newPassword, Boolean redirectedUserInstance)
at System.Data.SqlClient.SqlInternalConnectionTds..ctor(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, Object providerInfo, String newPassword, SqlConnection owningObject, Boolean redirectedUserInstance)
at System.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection)
at System.Data.ProviderBase.DbConnectionFactory.CreateNonPooledConnection(DbConnection owningConnection, DbConnectionPoolGroup poolGroup)
at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)
at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
at System.Data.SqlClient.SqlConnection.Open()
at Microsoft.Office.Server.Data.SqlSession.OpenConnection()
at Microsoft.Office.Server.Data.SqlSession.ExecuteNonQuery(SqlCommand command)
at Microsoft.Office.Server.Data.SqlDatabaseManager.HasAccess(String user)
at Microsoft.Office.Server.Administration.SharedDatabase.Microsoft.Office.Server.Administration.ISharedAccessControl.
SetAccessControl(SharedComponentSecurity security)
at Microsoft.Office.Server.Search.Administration.SearchSharedApplication.SynchronizeDatabase()
at Microsoft.Office.Server.Search.Administration.SearchSharedApplication.Synchronize()
at Microsoft.Office.Server.Administration.SharedResourceProvider.SynchronizeApplications(SharedComponentSecurity sharedApplicationSecurity)

Looking down at the bottom of the stack I could see the method that started this entire mess was one that runs within the OWSTimer. This was important because we knew this was not as a result of a user making a connection to the DB in the process of doing some kind of SharePoint operation on the Web Front End (WFE). This meant this error was not impacting their experience as well as when a job in the OWSTimer fails the operation will be retried at the next interval for the job.

As typically with many issues that present as a problem with networking we captured several network sniffs at the time of the events. We could see that the server was responding fine and there appeared to be no errors on the network, very fast responses basically all the time. In fact during the period in which the events were being thrown every attempted SQL connection from the time of the event and back 30 seconds succeeded.

Next I started looking into the ADO.NET source code and soon I developed a theory. So the theory was that we are inside of the ADO.NET ReadSync() method and we are getting a very small timeout value (possibly zero) passed in which caused us to not do the proper WaitForSingleObject() on the socket, basically passing 0 for the TIMEOUT which does not allow enough time for the response from the server. A TIMEOUT of zero basically causes the thread to release the remainder of its quantum and then immediately go back into a ready state to be scheduled back on the processor. So what would cause such a condition? ADO.NET calculates the timeout time by using the timeout passed in from the user code and calculates a time in the future with which to expire the connection. As the code progresses it compares the current time with this expiry time to get the number of milliseconds remaining and then uses that as the basis for the TIMEOUT on the WaitFor… methods. The problem with this approach is that it is susceptible to clock skews and corrections. So assume a 15 sec timeout and the connection attempt started at 12:00:00, the timeout would be at 12:00:15, now the timer service has figured out the clock time for the system is a bit slow and needs to be adjusted to 12:00:20, we just blew our timeout period. At this point you are probably saying to yourself this guy must be on crack if he really thinks this is what is going on. Well I am not on crack and you are correct this is not what was going on. If you think about it there is a really small window of opportunity for this to occur and to occur at the frequency we were seeing was very unlikely. What made this more unlikely was that we did not have the issue on just one server but rather dozens in various isolated environments.

The next step was to enable ADO.NET tracing to get a peek into what ADO.NET is really doing and try to ascertain why we are getting this timeout. Setting up ADO.NET tracing is trivial once you know how to do it. Below are the following files that I used.

Setup.cmd -- is what you run to install the necessary settings to perform the tracing.

Setup_trace.reg -- is the registry file that is imported.

ADO_NET.mof -- is the mof file that is compiled to enable the tracing.

_startTrace.cmd -- is the file you run when you are ready to start the tracing

Ctrl.guid.todd -- is the file that contains the IDs of the tracing handlers

_stopTrace.cmd -- is the file you run when you want to stop the tracing.

Setup.cmd

Regedit /s setup_trace.reg
Mofcomp ADO_NET.mof

Setup_trace.reg

Windows Registry Editor Version 5.00[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\BidInterface\Loader]
":Path"="c:\\windows\\Microsoft.NET\\Framework\\v2.0.50727\\ADONETDiag.dll"

ADO_NET.mof

#pragma classflags("forceupdate")
#pragma namespace ("\\\\.\\Root\\WMI")

/////////////////////////////////////////////////////////////////////////////
//
// ADONETDIAG.ETW

[
dynamic: ToInstance,
Description("ADONETDIAG.ETW"),
Guid("{7ACDCAC8-8947-F88A-E51A-24018F5129EF}"),
locale("MS\\0x409")
]
class Bid2Etw_ADONETDIAG_ETW : EventTrace
{
};

[
dynamic: ToInstance,
Description("ADONETDIAG.ETW"),
Guid("{7ACDCAC9-8947-F88A-E51A-24018F5129EF}"),
DisplayName("AdoNetDiag"),
locale("MS\\0x409")
]
class Bid2Etw_ADONETDIAG_ETW_Trace : Bid2Etw_ADONETDIAG_ETW
{
};

[
dynamic: ToInstance,
Description("ADONETDIAG.ETW formatted output (A)"),
EventType(17),
EventTypeName("TextA"),
locale("MS\\0x409")
]
class Bid2Etw_ADONETDIAG_ETW_Trace_TextA : Bid2Etw_ADONETDIAG_ETW_Trace
{
[
WmiDataId(1),
Description("Module ID"),
read
]
uint32 ModID;

[
WmiDataId(2),
Description("Text StringA"),
extension("RString"),
read
]
object msgStr;
};

[
dynamic: ToInstance,
Description("ADONETDIAG.ETW formatted output (W)"),
EventType(18),
EventTypeName("TextW"),
locale("MS\\0x409")
]
class Bid2Etw_ADONETDIAG_ETW_Trace_TextW : Bid2Etw_ADONETDIAG_ETW_Trace
{
[
WmiDataId(1),
Description("Module ID"),
read
]
uint32 ModID;

[
WmiDataId(2),
Description("Text StringW"),
extension("RWString"),
read
]
object msgStr;
};

/////////////////////////////////////////////////////////////////////////////
//
// System.Data.1

[
dynamic: ToInstance,
Description("System.Data.1"),
Guid("{914ABDE2-171E-C600-3348-C514171DE148}"),
locale("MS\\0x409")
]
class Bid2Etw_System_Data_1 : EventTrace
{
};

[
dynamic: ToInstance,
Description("System.Data.1"),
Guid("{914ABDE3-171E-C600-3348-C514171DE148}"),
DisplayName("System.Data"),
locale("MS\\0x409")
]
class Bid2Etw_System_Data_1_Trace : Bid2Etw_System_Data_1
{
};

[
dynamic: ToInstance,
Description("System.Data.1 formatted output (A)"),
EventType(17),
EventTypeName("TextA"),
locale("MS\\0x409")
]
class Bid2Etw_System_Data_1_Trace_TextA : Bid2Etw_System_Data_1_Trace
{
[
WmiDataId(1),
Description("Module ID"),
read
]
uint32 ModID;

[
WmiDataId(2),
Description("Text StringA"),
extension("RString"),
read
]
object msgStr;
};

[
dynamic: ToInstance,
Description("System.Data.1 formatted output (W)"),
EventType(18),
EventTypeName("TextW"),
locale("MS\\0x409")
]
class Bid2Etw_System_Data_1_Trace_TextW : Bid2Etw_System_Data_1_Trace
{
[
WmiDataId(1),
Description("Module ID"),
read
]
uint32 ModID;

[
WmiDataId(2),
Description("Text StringW"),
extension("RWString"),
read
]
object msgStr;
};

/////////////////////////////////////////////////////////////////////////////
//
// System.Data.SNI.1

[
dynamic: ToInstance,
Description("System.Data.SNI.1"),
Guid("{C9996FA5-C06F-F20C-8A20-69B3BA392315}"),
locale("MS\\0x409")
]
class Bid2Etw_System_Data_SNI_1 : EventTrace
{
};

[
dynamic: ToInstance,
Description("System.Data.SNI.1"),
Guid("{C9996FA6-C06F-F20C-8A20-69B3BA392315}"),
DisplayName("System.Data.SNI"),
locale("MS\\0x409")
]
class Bid2Etw_System_Data_SNI_1_Trace : Bid2Etw_System_Data_SNI_1
{
};

[
dynamic: ToInstance,
Description("System.Data.SNI.1 formatted output (A)"),
EventType(17),
EventTypeName("TextA"),
locale("MS\\0x409")
]
class Bid2Etw_System_Data_SNI_1_Trace_TextA : Bid2Etw_System_Data_SNI_1_Trace
{
[
WmiDataId(1),
Description("Module ID"),
read
]
uint32 ModID;

[
WmiDataId(2),
Description("Text StringA"),
extension("RString"),
read
]
object msgStr;
};

[
dynamic: ToInstance,
Description("System.Data.SNI.1 formatted output (W)"),
EventType(18),
EventTypeName("TextW"),
locale("MS\\0x409")
]
class Bid2Etw_System_Data_SNI_1_Trace_TextW : Bid2Etw_System_Data_SNI_1_Trace
{
[
WmiDataId(1),
Description("Module ID"),
read
]
uint32 ModID;

[
WmiDataId(2),
Description("Text StringW"),
extension("RWString"),
read
]
object msgStr;
};

/////////////////////////////////////////////////////////////////////////////
//
// System.Data.OracleClient.1

[
dynamic: ToInstance,
Description("System.Data.OracleClient.1"),
Guid("{DCD90923-4953-20C2-8708-01976FB15287}"),
locale("MS\\0x409")
]
class Bid2Etw_System_Data_OracleClient_1 : EventTrace
{
};

[
dynamic: ToInstance,
Description("System.Data.OracleClient.1"),
Guid("{DCD90924-4953-20C2-8708-01976FB15287}"),
DisplayName("System.Data.OracleClient"),
locale("MS\\0x409")
]
class Bid2Etw_System_Data_OracleClient_1_Trace : Bid2Etw_System_Data_OracleClient_1
{
};

[
dynamic: ToInstance,
Description("System.Data.OracleClient.1 formatted output (A)"),
EventType(17),
EventTypeName("TextA"),
locale("MS\\0x409")
]
class Bid2Etw_System_Data_OracleClient_1_Trace_TextA : Bid2Etw_System_Data_OracleClient_1_Trace
{
[
WmiDataId(1),
Description("Module ID"),
read
]
uint32 ModID;

[
WmiDataId(2),
Description("Text StringA"),
extension("RString"),
read
]
object msgStr;
};

[
dynamic: ToInstance,
Description("System.Data.OracleClient.1 formatted output (W)"),
EventType(18),
EventTypeName("TextW"),
locale("MS\\0x409")
]
class Bid2Etw_System_Data_OracleClient_1_Trace_TextW : Bid2Etw_System_Data_OracleClient_1_Trace
{
[
WmiDataId(1),
Description("Module ID"),
read
]
uint32 ModID;

[
WmiDataId(2),
Description("Text StringW"),
extension("RWString"),
read
]
object msgStr;
};

_startTrace.cmd

@Logman start MyTrace -pf ctrl.guid.todd -ct perf -o Output.etl -ets

Ctrl.guid.todd

{7ACDCAC8-8947-F88A-E51A-24018F5129EF} 0x00000000 ADONETDIAG.ETW
{C9996FA5-C06F-F20C-8A20-69B3BA392315} 0xFFFFFFFF System.Data.SNI.1

_stopTrace.cmd

@Logman stop MyTrace -ets

Once the trace is complete you end up with a potentially huge Output.etl file. So once I opened the file in my favorite text editor (UltraEdit) I needed to find the error. So I began hunting around for the string “{WINERR}” with the actually error number preceding this string. The only errors I could find were 258 (WAIT_TIMEOUT) and 10065 (WSAEHOSTUNREACH). Both seemed relevant and both occurred on the same thread. Using LogParser I was able to break out the huge file into something more manageable. One of the columns you can use to do this is the ThreadID. My errors occurred on threaded 3136 so I used this command to break out the file:

LogParser.exe "SELECT EventNumber,Timestamp,EventDescription,ThreadID,msgStr INTO bid_3136.csv FROM Output.etl WHERE ThreadID=3136" -oTsFormat:"yyyy-MM-dd:hh:mm:ss.llnn" -fMode Full

I narrowed my search even further and finally I was able to figure out what was going on. Using EventNumbers we can see at 62463 we attempted to connect a socket, and at 62515 (the next trace item on this thread) we can see this event occurred 21 seconds later with our destination unreachable error. We then retry the connection, but remember our connection timeout of 15 seconds is already past, so in 62647 we have a timeout of 0, we send on the stocket and then attempt to wait on it and get the error in 62651 which is our WAIT_TIMEOUT which is the result of calling WaitForSingleObject on the socket handle with a TIMEOUT of 0. This is the error that is logged in the event log however it is not the real reason we failed to connect. Rather it was the first error we needed to focus on.

EventNumber	Timestamp	EventDescription	ThreadID	msgStr
62463	2007-11-16:14:33:28.367774700	System.Data.SNI.1	3136	enter_06 <Tcp::SocketOpenSync\|API\|SNI> AI: 000000001D52EE00{ADDRINFO*}, ai_family: 2, event: FFFFFFFFFFFFFFFF{HANDLE}, timeout: -1
62515	2007-11-16:14:33:49.344609000	System.Data.SNI.1	3136	<Tcp::SocketOpenSync\|RET\|SNI> 10065{WINERR}
62517	2007-11-16:14:33:49.344618700	System.Data.SNI.1	3136	<Tcp::Open\|ERR\|SNI> ProviderNum: 7{ProviderNum}, SNIError: 0{SNIError}, NativeError: 10065{WINERR}
62519	2007-11-16:14:33:49.344631800	System.Data.SNI.1	3136	<Tcp::Open\|RET\|SNI> 10065{WINERR}
62646	2007-11-16:14:33:49.348822900	System.Data.SNI.1	3136	enter_01 <SNIReadSync\|API\|SNI> 311#{SNI_Conn}, pConn: 00000000008BF2F0{SNI_Conn}, ppNewPacket: 000000002380DB18{SNI_Packet*}, timeout: 0
62647	2007-11-16:14:33:49.348827800	System.Data.SNI.1	3136	enter_02 <Tcp::ReadSync\|API\|SNI> 312#, ppNewPacket: 000000002380DB18{SNI_Packet**}, timeout: 0
62648	2007-11-16:14:33:49.348832000	System.Data.SNI.1	3136	<SNI_Packet::SNIPacketAllocate\|API\|SNI> pConn: 00000000008BF2F0{SNI_Conn*}, IOType: 0
62649	2007-11-16:14:33:49.348836000	System.Data.SNI.1	3136	<SNI_Packet::SNIPacketAllocate\|SNI> 4#{SNI_Packet} from pool for 311#{SNI_Conn}
62650	2007-11-16:14:33:49.348839400	System.Data.SNI.1	3136	<SNI_Packet::SNIPacketAllocate\|RET\|SNI> 0000000000875740{SNI_Packet*}
62651	2007-11-16:14:33:49.348893400	System.Data.SNI.1	3136	<Tcp::ReadSync\|ERR\|SNI> ProviderNum: 7{ProviderNum}, SNIError: 11{SNIError}, NativeError: 258{WINERR}

We then went through a battery of config changes to see if we could knock this one out, we checked the IP settings and routing tables to confirm everything was correct. We checked GPO IPSec policies and none were being applied. We disabled or removed additional NICs that were not being used. We removed load balancers, AV software, etc but nothing helped.

We also performed a TDIMon trace and this confirmed exactly what we found in the ADO.NET logs.

1469 4:18:34 PM w3wp.exe:3820 88F44518 TDI_CONNECT TCP:0.0.0.0:2283 40.1.221.120:80 HOST_UNREACHABLE-1792

Next I attempted to use a Debugger however the logistics to make this reality were very difficult and once attached I had limited time to try to reproduce the issue. We seemed to run clean with the debugger which typically means we have some sort of timing issue or race condition (not the case here however).

Next I attempted to use iDNA which is a really cool technology developed by MSResearch which can trace every operation the machine performs. You can then load the log into the debugger and step forward or back in time, aka time traveling. Unfortunately there are some limitations, it does not work on x64 and it does not work within a VMWare VM. Our test environment was both.

The customer was on SP1 of Windows 2003 and we upgraded to SP2, while we did see some improvement it was only marginal.

Knowing this was something within the customer’s environment it must be something that applies to all machines so I received a copy of their build documents and attempted to build an identical machine using their process however this did not prove helpful.

Finally we decided to use a special build of tcp.sys that dumped a message to a DebugDiag window when a Destination Unreachable error occurred. Fortunately there are only a few places within tcp.sys where this error is returned. Once we received the log we could see were the message was being returned and looking at the code we saw the code path necessary to get us to that place meant IPSec was enabled. BUT we checked IPSec right. Wrong, we did not check to see what policies were being applied at the local registry. To determine whether IPSec policies are being applied from either the local registry or through a Group Policy object (GPO) we followed these steps:

We Installed Netdiag.exe from the Windows Server 2003 CD by running Suptools.msi from the Support\Tools folder.
Opened a command prompt and changed directories to %ProgramFiles%\Support Tools. (Assumes you chose the default install path).
Ran the following command to verify that there is not an existing IPSec policy assigned to the computer: netdiag /test:ipsec.

Now if there was no policy we would have expected to see a message similar to “IP Security test…….:Passed IPSec policy service is active, but no policy is assigned” however what we found was that although there was no Group Policy IPSec policy being applied someone (namely the security team) had gone in and applied IPSec policy directly to the machine. In my experience this is typically not done just because this practice is an administrative headache and is riddled with problems. What happens when you update your policy? What about if you miss applying a policy to one machine? What if you apply an outdated policy to a machine? You get the point…

Here is one of the entries from the IPSec log, note we are blocking TCP source port 2283.

Filter name: 2
Connection Type: ALL
Weight                  : 34603266
Source Address          : xx.x.xxx.xx        (255.255.255.255)
Destination Address     : <Any IP Address> (0.0.0.0         )
Protocol                : TCP      Src Port: 2283    Dest Port: 0
Mirrored                : no
Outbound Action         : Blocking

There were some 30+ blacklisted ports the next table gives the full list.

Protocol UDP Src Port: 1080
Protocol TCP Src Port: 1080
Protocol UDP Src Port: 2283
Protocol TCP Src Port: 2283
Protocol UDP Src Port: 2535
Protocol TCP Src Port: 2535
Protocol UDP Src Port: 2745
Protocol TCP Src Port: 2745
Protocol UDP Src Port: 3127
Protocol TCP Src Port: 3127
Protocol UDP Src Port: 3128
Protocol TCP Src Port: 3128
Protocol UDP Src Port: 3410
Protocol TCP Src Port: 3410
Protocol UDP Src Port: 5554
Protocol TCP Src Port: 5554
Protocol UDP Src Port: 8866
Protocol TCP Src Port: 8866
Protocol UDP Src Port: 9898
Protocol TCP Src Port: 9898
Protocol UDP Src Port: 10000
Protocol TCP Src Port: 10000
Protocol UDP Src Port: 10080
Protocol TCP Src Port: 10080
Protocol UDP Src Port: 12345
Protocol TCP Src Port: 12345
Protocol UDP Src Port: 17300
Protocol TCP Src Port: 17300
Protocol UDP Src Port: 27374
Protocol TCP Src Port: 27374
Protocol UDP Src Port: 65506
Protocol TCP Src Port: 65506

So what was it able this IPSec policy that was a deal breaker? Several of these blocked ports fell within the ephemeral port range and when we attempted to use one of these ports we would fail.

So how do you fix this issue? According to all documentation the fix is to set the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ReservedPorts to exclude a range of ports so that TCP did not attempt to use them. This makes since, knowing they are blocked to remove them from the ephemeral pool of possible ports. The KB article that documents this key however does not mention that multiple ranges can be included. By adding ranges such as 1080-1080 and 2282-2283 one can exclude these ports from the ephemeral pool. There is however an open question on whether this actually works or not. The customer chose to use another workaround mainly the built in firewall in Windows 2003 Server.

So why are these ports being blocked? It seems the security folks connect to each server and make the IPSec changes to block ports that have known vulnerabilities however they failed to tell anyone that they actually do this so this is likely why it did not make it into their build documents.

.Net Framework Version Overview

Toddca — Wed, 08 Aug 2007 14:03:57 GMT

I am frequently asked about the various .Net framework versions floating around. As the .Net framework continues to go through its various revs the waters will only become muddier. Here is a quick overview of each version we have to date…

.Net 1.0 – This was the initial release of the framework which as of today only .Net 1.0 SP3 is currently supported by PSS. This only shipped as x86.

.Net 1.1 – This is a side-by-side release of the framework in which no dependencies on 1.0 exist. Hotfixes and Service packs for this version do not affect other framework versions. This only shipped as x86 and the latest Service Pack is SP1. This version also shipped inside the OS on Windows 2003 RTM but only in the x86 SKU. For x64 and IA64 versions of Windows 2003 there is no .Net framework installed by default. The x86 SP1 for Windows 2003 updates the 1.1 framework however it is SP1+ in that it does not have the same binaries as let's say a Windows 2000 machine with .Net 1.1 SP1 installed.

.Net 2.0 – This is a side-by-side release just as .Net 1.1. This version ships as x86, x64, and IA64. Windows 2003 R2 ships this version but does not install it by default. Using add/remove programs on any SKU will allow for installation. There currently is no service pack for this version. The x86 and x64 redist packages can each be installed side-by-side on a single x64 system.

.Net 3.0 – This is the first add-on framework. It adds functionality in the form of WPF, WCF, and WF, plus upgrades the 2.0 binaries by adding a few necessary fixes to make the new components function properly. This version shipped with all SKUs of Vista and has a redistributable package as well. The 3.0 redist package will install the 2.0 framework should it not be present or will upgrade an existing 2.0 installation. The x86 and x64 redist packages can each be installed side-by-side on a single x64 system. Currently there is no Service pack available.

.Net 3.5 – This is another side-by-side for 2.0 and 3.0 which adds functionality and updates the binaries of the previous two frameworks. This version has not been released and not much about it is public at this point but you can assume an x86, x64 and an IA64 version will continue to be available. You can probably also assume this will debut with Windows 2008.

Windows SharePoint Services 3.0 Remote Blob Storage API

Toddca — Tue, 07 Aug 2007 02:16:00 GMT

Probably one of the worst KB articles I have seen lately introduces, what has the potential to be a really exciting new feature of WSS 3.0/4.0 – Remote Blob Storage (RBS). This interface allows the storage of "blobs" outside of SQL server in a kind of BlobBank (I call dibs on this name. J). Blobs are the stream of content, a byte[] for those dev heads, which represent files within SharePoint. They are stored alongside their metadata in SQL. Having the ability to move these blogs to external storage systems is a huge win for some whom have TB of SQL storage and whom want to reduce the dependency on SQL for this type of storage.

Simon Skaria plans on blogging about the interface so I will not go into that here however what I did want to cover were some of the pros and cons or as some would say "considerations" when evaluating the Remote Blob Storage API.

Pros

Ability to use storage other than SQL Server for blobs.
Ability to leverage a lower TCO storage solution for blobs. This point should be scrutinized for each enviroment especially when you consider some of the Cons pointed out below.

Cons

Without ISV involvement there is no mechanism to ensure Backup and Restore is consistent between SQL and external storage solution. Since part of the blob, the ID is still stored in SQL and the blob itself is stored elsewhere these items must remain in a consistent state. So bottom line here is you must be careful when planning your backup and disaster recovery strategies.
Lack of documentation.
Depending on the external solution chosen it may be slower than SQL which would have obvious impact to the performance.
The provider works at the farm level only.
Removing the provider once deployed is going to be a huge problem should one need to back out.
This is custom code that runs all the time within SharePoint; if there is a performance problem, memory leak, etc it will impact SharePoint stability greatly.
The O12 implementation is not fully baked and will very likely change for O14. So the likelihood that an O12 provider will need to be rewritten for O14 is very probable.
There is no migration path for the provider in an existing SharePoint deployment. New blobs will be stored with your provider while existing blogs will remain in SQL. You may touch the blogs and cause them to be migrated however that has a whole set of other problems.
To date there is very little experience rolling out this API. So the real world knowledge is very tribal deep within MSFT and not likely to make it into the public domain in any quick manner.
While the API will be supported however it is highly unlikely the support teams will have training or knowledge about its proper use.
It is very unclear what the experience will look like while upgrading an O12 using this solution to O14.

BTW if anyone writes a provider I would love to hear about it!

Thanks
Todd

Download your Hotfixes!

Toddca — Fri, 27 Jul 2007 15:34:00 GMT

Up to this point Microsoft has always required customers to make a phone call into Microsoft Product Support to receive a hotfix. Today we have made available a web application that allows customers to fill out a simple web form and receive the hotfix by email.

Here is how it works: The form on the site has field entries for the following information:

Country/Region (Pulldown menu)

KB article number (Text entry)

Platform (Pulldown menu)

Product Language (Pulldown menu)

E-mail address (Text entry)

You enter the data listed above and select the "Submit" button . You are then taken to a submission confirmation webpage. This webpage lets you know that you should receive a response from a Microsoft Professional within 8 business hours. The e-mail response that you receive looks like the automated hotfix e-mail that you may have seen should you have ever used the previous call in method.

Happy Hotfixin'.

Todd

Moss & SharePoint Related MCTS Certification Information

Toddca — Thu, 14 Jun 2007 18:43:00 GMT

Recently I have been looking into MOSS related certifications and ran across the MCTS certifications. I have narrowed the huge list of certifications and exams down to just those that are MOSS 2007 and WSS V3 specific and have provided links below.

MCTS Certification

Configuration

Windows SharePoint Services 3.0, Configuration

Exam: 70-631: Configuring Windows SharePoint Services 3.0

Related Course(s) : 5060, 5244, 5245, 5246, 5247, 5248, 5249, 5403, 5942, 5943

E-Learning: Collection 5403: Implementing Microsoft Windows SharePoint Services 3.0

Microsoft Office SharePoint Server 2007, Configuration

Exam: 70-630: TS: Configuring Microsoft Office SharePoint Server 2007

Related Course(s): 5061, 5250, 5251, 5252, 5253, 5254, 5255, 5404

E-Learning: Collection 5404: Implementing Microsoft Office SharePoint Server 2007

Application Development

Microsoft Windows SharePoint Services 3.0, Application Development

Exam: 70-541: TS: Microsoft Windows SharePoint Services 3.0 - Application Development

Related Course(s): 999, 5385, 5386, 5387, 5388, 5389, 5390, 5391, 5392, 5393, 5394, 5395, 5396, 5397, 5398

E-Learning: Collection 5385: Developing Solutions with Microsoft Windows SharePoint Services 3.0 and Visual Studio 2005

Technology Specialist: Microsoft Office SharePoint Server 2007, Application Development

Exam: 70-542: TS: Microsoft Office SharePoint Server 2007, Application Development

Related Course(s): None

E-Learning: None

Moving To SharePoint

Toddca — Tue, 29 May 2007 00:46:00 GMT

Since coming to Developer Support in 2003 I have been working with ASP.NET and IIS. 4 years in any group at Microsoft is a good stint and it was time that I moved on. Because I love working with .Net and web technologies SharePoint seemed like a likely choice. Given SharePoint's huge popularity I felt this provided me with an opportunity to learn a technology that was here to stay and which would only get larger. As a platform there is just a ton that you can do with SharePoint and since it is built on top of ASP.NET I am not totally in the woods when it comes to learning this new product.

So going forward my blogs will be more SharePointy in focus and hopefully (fingers crossed) more frequent and (again fingers crossed) as technically accurate and spelling and grammar error free as possible.

WSS 3.0 32bit on x64

Toddca — Wed, 16 May 2007 00:29:00 GMT

Question:

So what happens when you have an x64 development box running Windows 2003 R2 x64 Enterprise with IIS6 in WOW64mode and you want to install the 32bit version of WSS 3.0?

Answer:

---------------------------

Setup Errors

---------------------------

Setup is unable to proceed due to the following error(s):

- This 32-bit product must be run on a 32-bit Operating System. For 64-bit support, please install the 64-bit version of this product.

- Internet Information Services is running in 32-bit emulation mode.

Correct the issue(s) listed above and re-run setup.

---------------------------