Welcome to my blog mainly about SharePoint

My fellow co-workers and I have been dealing with an extremely slow build > render process when we are developing SharePoint solutions that are deployed to the BIN folder for over a year now.

We are all using are own Windows Server 2003 image hosted on a VMware ESX Server farm with tons of other VM’s.

We all know that SharePoint can take anywhere from 30 seconds to 2 minutes to fire up the very first time you hit it and we accept that fact. However, we found ourselves waiting for up to 1 minute after making some code changes and perform a build that deployed the DLL to the BIN folder for SharePoint to render.

This can become extremely frustrating and frankly a waste of our time. I had gotten to a point where I just accepted the fact we had to deal with the slowness because no amount of tweaking we did on the VM (adding memory, CPU, etc) seemed to make a difference.

One of my co-workers did not want to accept the fact continued to investigate/troubleshoot the issue. He happened to come across the Understanding ASP.NET Dynamic Compilation (http://msdn.microsoft.com/en-us/library/ms366723.aspx) article, more specifically the section called Optimizing Dynamic Compilation. This section mentions an attribute you can add to your web.config file called optimizeCompilations which requires you to install a hot fix (KB961884). This attribute is going to be part of the .NET Framework 4.0 when it ships.

We were all amazed at the difference this attribute made to our development process. In one instance, it cut the time from 1 minute 10 seconds to 12 seconds (80% improvement!!).

The following screenshot shows the change in time with the attribute set to false and then set to true (fairly vanilla SharePoint application). The WebTimer utility just makes a simple web request to my SharePoint site.

Here is the order events described above:

optimzedCompilations attribute in web.config was set to “false”

Performed IISRESET to baseline

Executed WebTimer (40 seconds)

Modified some code in my solution and performed a build (which went into the BIN folder)

Executed WebTimer (30 seconds)

Switched optimizedCompilations to “true”

Performed IISRESET to baseline

Executed WebTimer (40 seconds)

Modified some code in my solution and performed a build

Executed WebTimer (12 seconds)

Needless to say, we have happy developers again!

You may or may not see much advantage to this if you are developing on a physical machine or on a workstation edition of a virtual client (VPC, VMware Workstation, or Virtual Box). But if you are running in an environment where the resources are being shared or you feel your build to render process seems slower than it should be, I highly recommend you try this hot fix / attribute out.

There is a feature in my SharePoint URL Shortener solution that was not included in the video I posted on YouTube recently. I thought I would take the time to spotlight this feature because it may not be too obvious.

The video highlights the ability to generate a short URL by using the drop down menu from within a list or library, for example:

However, sometimes you may have the need to shorten the current URL you are on within a SharePoint site (it does not have to be a list item or document). My SharePoint URL Shortener adds a link to the Welcome menu located in the top right corner of the screen that when clicked will generate a short version of whatever URL you are currently viewing.

Lets say you wanted to create a survey and send it out to your users. You can now click on the Respond to this Survey button:

Which will take you to some awful long URL which you would generally copy and paste into an email, or a SharePoint announcement and send out to your users.

With SharePoint URL Shortener, you can now click the drop down on the Welcome menu and select Generate Short URL and it will generate the short URL version:

You can now include this shortened URL in an email message or post it to an announcement list within SharePoint.

After many iterations and delays I am pleased to announce that my SharePoint Url Shortener (initial version) is finally here! There is still some work to be done on this but I have decided to release it in its current state to start getting some feedback from the community.

Here is a demonstration of the process – from feature activation to Url generation:

I’ll be publishing the Codeplex project sometime this weekend (probably Saturday) so be on the look out.

Some organizations want to leverage the publish links to Office 2007 client feature that SharePoint 2007 offers without enabling My Sites. The publish links to Office 2007 relies on the same update mechanism that the My SharePoint Sites feature uses.

If you have read any of my posts in the past on this topic you know that these features were designed around the fact that users would have My Sites. In fact, the very action of setting your default My Site is what triggers these features to become active.

Is is very possible to use these features without enabling My Sites but it will require you to update some registry settings on your client PC’s. Most organizations will deploy these types of settings using a GPO.

The registry setting you want to add can be found under:

HK_CurrentUser\Software\Microsoft\Office\12.0\Common\Portal

Add a string value called PersonalSiteURL and point it to any root SharePoint site in your farm that all your users have access too. Normally the users My Site URL would be listed here.

Once you have populated this registry setting, you should start seeing your published links appear once the user attempts to access My SharePoint Sites the first time via an Office 2007 application.

I also developed a utility that you can run, specify your SharePoint URL, and it will return all the URL’s it believes your client PC should get published. For example:

I have hit a strange problem today and I am trying to wrap my head around why this is happening. Perhaps the SharePoint community has run into this before and has some insight as to what is causing it.

I have some custom code that enumerates each list then items in the list to do some security report processing. However, every now and then we will run across a user who has exceed their site quota and when our custom code runs we receive the following SPException:

Microsoft.SharePoint.SPException occurred Message="Your changes could not be saved because this SharePoint Web site has exceeded the storage quota limit. You must save your work to another location. Contact your administrator to change the quota limits for the Web site." Source="Microsoft.SharePoint" ErrorCode=-2130575282 StackTrace: at Microsoft.SharePoint.Library.SPRequest.GetListItemDataWithCallback(String bstrUrl, String bstrListName, String bstrViewName, String bstrViewXml, SAFEARRAYFLAGS fSafeArrayFlags, ISP2DSafeArrayWriter pSACallback, ISPDataCallback pPagingCallback, ISPDataCallback pSchemaCallback) at Microsoft.SharePoint.SPListItemCollection.EnsureListItemsData() at Microsoft.SharePoint.SPListItemCollection.Undirty() at Microsoft.SharePoint.SPBaseCollection.System.Collections.IEnumerable.GetEnumerator()

My code does not attempt to update any information within the SharePoint site, so why would simply accessing the items in a list cause this error message?

To prove to myself that I am not writing any information to the list I decided to navigate to this list using the SharePoint Manager 2007 tool. As you can see from the screenshot below, I received the same error message just by clicking on the library:

Has anyone else seen this before? Any guidance would be appreciated.

I’ll continue my quest to discover the reason – I am hoping it is something obvious that I am overlooking.

This may seem obvious now but I through me for a loop for a few minutes yesterday when a co-worker asked me why he was getting redirected to the SharePoint access denied page when he attempted to add a new item to a list.

I checked the permissions on the list and he had contribute rights; hence the reason why he could see the New drop down button on the list. However, after he filled out the form and click Ok he was immediately re-directed.

After a few minutes I realized that he had the Edit access option of the Item-level Permissions on the list set to None.

Doh! – of course he is getting Access Denied

When adding a new item to a list, the SharePoint object model will,

Call the SPList.Add() method,

Update the properties of the SPListItem, then

Call the SPListItem.Update() method <—Access is denied

Understand how SharePoint updates the item, you can understand why setting the Edit access option to None would cause an issue.

From an end-users perspective, seeing the New option but getting denied could lead to major confusion. Knowing this as a possible scenario, you can at least be better equipped to help troubleshoot and solve the issue.

Wow! What an interesting morning. I arrived at work today to discover that all our “My Site” profile information (and related information) has been deleted from our environment.

I figured out what happened and thought I would share my findings with the community (I’ll most likely be opening a support case with Microsoft to try get this resolved).

Situation

Our environment performed an incremental profile import at 11pm last night. However, at the time the import process began the domain controller we have specified in our profile import connections setting was unavailable.

At this point, SharePoint flagged all the profile accounts in the database to be deleted. I verified this by looking at the bDeleted column in the dbo.UserProfile view in the Shared Services Provider database – all the values were set to “1”.

“When a user is deleted, starts a workflow on that user’s My Site. The default behavior is to send an e-mail message to the manager with a link to the deleted user’s site. The e-mail message contains a request to the manager to move any documents or data that the manager wants to preserve, because the site might be deleted in the future.”

Please note that this job runs Hourly.

What this page fails to mention is it also wipes out all profile specific data. Not only does it wipe out all profile data (stuff not imported from AD); it also deletes any user Quick Links, Colleague Tracker, Profile Picture, etc.

At least the users documents, etc are safe – but what a pain!

In the ULS, I was seeing the following error message:

“Domain {0} cannot be found.”

Followed by:

“MySiteCleanup: Unable to change owner of MySite for user profile because the new owner was not specified.”

Conclusion

It seems to be a major flaw with this process if SharePoint flags everyone to be deleted simply because the domain controller used for the profile imports is unavailable (for whatever the reason is).

Now domain controllers are rarely unavailable but you should at least be aware of this flaw and plan accordingly.

I am just thankful I did not have the “Site use confirmation and deletion” options enable to automatically delete dead webs. Would have completely ruined my day.

By the way, this environment is running version 12.0.0.6504 (which is the Approval 2009 Cumulative Update).

I’d like to take a moment to congratulate the Muhimbi for shipping MuSH; their version of the URL shortener for SharePoint. As many of you know I have been working on and off on my open sourced version for sometime now and it is good to finally see someone else attempting to tackle the same problem I was attempting to solve (see http://paulliebrand.com/2008/09/08/tinyurl-like-feature-for-sharepoint/).

I had an opportunity to test MuSH recently and for the most part it fundamentally works the same way my version works. The installation process of MuSH was pretty straightforward; it is delivered as a SharePoint WSP solution that gets deployed to your farm.

To create a shortened URL, you navigate to a document library, find the item you want to shorten, click the drop-down and select Shorten URL. This process ultimately shortens the URL and you get an opportunity to copy the URL to the clipboard.

The major difference between Muhimbi’s version and mine is that their shortens the URL to the SharePoint list item itself not the document. Now of course the challenge here is that on some occasions you want it to link to the list item itself and sometimes you may want to link it DIRECTLY to the document itself. To me, the linking directly to a document is more important than linking to the SharePoint list items (in my environment / experience anyway).

I provided this feedback to the Muhimbi team and they are considering adding it to a future version of the product.

For those of you that can no longer wait for my version, you can pick up a copy of MuSH for $199.00.

With all this said and done, I really hope Microsoft considers adding a URL shortener directly into SharePoint 2010 – this is definitely one of those things I hear people complain the most about and (until now) nobody has solved yet.

In the coming weeks I’ll be picking up the development effort on my version of a URL Shortener for SharePoint; this other large project I am working on is coming to a close.

I am still planning on releasing an open sourced version of the “TinyUrl" Feature for SharePoint later this year. However, until then you can also keep your eye on MuSH, a URL shorter by Muhimbi. It is current priced at $199.00 and is in a closed beta – of which I am trying to get signed up for.

Muhimbi is looking for some beta testers for the product – if you interested, I would hit them up on Twitter at @Muhimbi.

About

My name is Paul Liebrand and I currently reside in Southern California. I plan on writing about anything related Microsoft SharePoint.

Because of other interests I have , you may also see posts off topic here.

I also started a community wiki site that will be dedicated to Windows SharePoint Services and related technologies. I update it has frequently as I can, but I encourage others to check it out and contribute where possible. The site can be found at http://www.wsswiki.com.