Viewpoint : SharePoint 2007

Chicago SharePoint Business Strategies User Group Presentation: Intro to CQWP

Kim Frehe — Mon, 20 Feb 2012 17:14:00 GMT

I was honored to give a presentation at the February 2012 Chicago Microsoft SharePoint Business Strategies User Group meeting. It was a great group and I had a lot of fun talking about my favorite subject, SharePoint, and my favorite web part, the 2010 Content Query Web Part (CQWP).

A few attendees asked for the slides so I thought I’d post them here for everyone. The notes view will show you my some of my comments, and the examples should be self-explanatory. If not, please feel free to let me know at kfrehe@rightpoint.com.

To summarize, the CQWP is a powerful tool that SharePoint provides, out of the box, to give you access to information across your site collection. The CQWP collects information and displays it for you in one web part on a page, where you can then group, filter and sort the information in a meaningful way.

This presentation:

· Gives a high level overview of what the CQWP is,

· Shows some examples of how we have used the CQWP internally and on some of our projects,

· Includes print screens with descriptions of adding a web part to a page,

· Provides requirements for having access to create and use CQWP’s,

· Offers some tips and tricks for using the CQWP.

Link to Presentation

Enjoy!

To join our next Chicago Microsoft SharePoint Business Strategies User Group meeting, held on the 2^nd Tuesday of the month, please sign up at http://www.meetup.com/sharepoint . The topics change every month and are listed one month prior to the meeting date.

SharePoint 2007 Timer Job Woes

Jeremy Williams — Tue, 08 Nov 2011 21:54:00 GMT

Scenario: You realize one day that you are no longer receiving alerts from SharePoint. Upon investigation, you notice that you can create a new alert and receive the notification email that an alert has been created for you. However, you receive no notification emails after the first one is sent for that particular alert. Upon further investigation, you discover that no timer jobs have been executed in a couple of days.

Solution One: Thinking that it’s the typical case of a dead SharePoint Timer Job, you go and restart the SharePoint Timer Job Service. After restarting the windows service, waiting patiently, (and impatiently running stsadm –o execadmsvcjobs) you realize that this isn’t the problem, so you continue to …

Solution Two: You decide to attempt clearing the Timer Job cache directory on the SharePoint server…This is better documented at Joe Rodgers Blog. Essentially, you navigate to the All Users/Program Data directories, and clear out the files in the SharePoint—>Config—>GUID folder, then restart the timer service and wait for it to rebuild (and execute) all of the files. After going through the same patient waiting, you (sadly) realize that this didn’t fix the issue either.

Sanity Check: Go through all of your service accounts and their related services and make sure that they are:

Running
Running under the correct Identity

After going through your Sanity Check, try the first two solutions…just to make sure you aren’t going crazy (after all, it’s possible)

Safety-First: Now you’re (probably) starting to get a bit nervous about the overall health of your SharePoint 2007 Server (and depending on how many users are angry at you, you might be nervous about your own health)… Before proceeding, take a deep breath and MAKE SURE YOU HAVE BACKUPS. I don’t care if you need to call up your off-site tape storage people and have them make an emergency delivery…get those backups!! [It’ll be the cheapest insurance you’ve ever not-paid-for]

Big Hammer Solution: You’re going to be running the SharePoint Products and Technologies Configuration Wizard…This will (effectively and hopefully) clean up whatever issue you were having in your environment this whole time. Remember that running this will take SharePoint offline in a BIG way (for a minimum of 5 minutes, and with no conceivable upper-bound). Once you’re ready, go ahead and launch the application from start…

…Hiccup 1: You’re presented with the following error message, “unable to upgrade SharePoint products and technologies because an upgrade is already in progress”. Of course, that’s quite annoying, but don’t worry the fix is relatively straightforward [note: my steps below are modified from those presented here: http://blogs.technet.com/b/manjesh/archive/2009/11/10/unable-to-run-sharepoint-configuration-wizard-error-unable-to-upgrade-sharepoint-products-and-technologies-because-an-upgrade-is-already-in-progress.aspx]

Stop the Windows SharePoint Services Timer service.
On the SharePoint Server where Central Administration Site is hosted browse to C:\Documents and Settings\All Users\Application Data\Microsoft\SharePoint\Config\<guid>
Move all the xml files to another location.
Also backup the cache.ini file. Then Edit the cache.ini and replace the current value with "1".
Restart the Windows SharePoint Services Timer service. New xml files will start appearing in the guid folder.
Verify the cache.ini now contains its previous value (or verify that the value is no longer "1"; any non-1 value is fine).
Run the command from the sharepoint server "stsadm -o setproperty -pn command-line-upgrade-running -pv no" (without quotes)
Run the command from the sharepoint server "stsadm -o execadmsvcjobs" (without quotes)
Open up Central Administration and Navigate to Timer Job Status (under Operations). Look for a One-Time job of ‘Upgrade Job’. If you find it, delete it.
Run SharePoint Products and Technologies

Big Hammer Solution (cont’d): Alright, so now your SharePoint server is running through it’s paces on the upgrade/configuration… Step 8 will probably be the longest step in the world…so go grab some coffee, relax, etc… If it seems that it’s hanging on Step 8, you can run this command from the command prompt. The (following) command will effectively cancel your previous upgrade efforts, and will restart everything. Once you execute this command, it’s best to step away and stop looking at the system…You’ll only serve to drive yourself a bit mad. After (what could very well be a few hours) the job will complete and your farm should (once again) be in a sustainable, and running state.

psconfig -cmd upgrade -inplace b2b -wait -force

Validating it all worked: Go ahead and check your Timer job to make sure that it’s executing jobs now…Assuming that it is, you can go ahead and make sure that your Alerts are working again too.

Phew! I’m glad that’s over…Now what the FLIP happened?!?!?! In the particular case that I’m walking through above, there were a couple of factors at play… There was a SQL server failure, service account identity changes, and a previous upgrade (service pack/cumulative update) that appeared to never have completed… By running SharePoint Products and Technologies Configuration Wizard (psconfig), we allowed SharePoint to recompile (read: recompose) itself a bit, and also execute the upgrade job properly. Once this job was able to complete, the timer job had the ability to execute jobs as designed.

And yes, I realize that I didn’t actually answer what happened here, since I’m not terribly sure of the actual root cause. A service pack/CU package may have been halted mid-way, or perhaps SQL went offline during a patching window, or perhaps the gremlins that run SharePoint were just a bit angry the particular day this all went down. However, the solution above should help anyone in a similar situation, since the issues encountered represent some fairly serious SharePoint issues…

Sharepoint Online for Office 365: People Search using SPServices and jQuery

Jarrod Godfrey — Wed, 13 Jul 2011 21:44:00 GMT

One of my recent projects involved creating a custom web part for SharePoint Online (part of the Office 365 suite). Unfortunately, one of the limitations of developing for the cloud is that you’re bound to a sandboxed solution environment. This particular project required retrieving data from the User Profile Service using the following SharePoint web service:

1.) Query Web Service

http://msdn.microsoft.com/en-us/library/ee872313.aspx

Now, if I were not limited to a sandboxed environment my first approach would be to use the SharePoint object model. In the sandbox, however, we are limited to the Microsoft.SharePoint.dll and any assemblies which include the attribute: “AllowPartiallyTrustedCallersAttribute” as outlined here:

http://msdn.microsoft.com/en-us/library/ee539417(office.14).aspx

My solution….. use the SPServices library to make the web service calls from the client side.

SPServices is a jQuery library that wraps SharePoint’s Web Services calls using the .ajax() method behind the scenes, I would recommend to anyone reading this blog post to check out their web site for more information. I found the library very easy to use and their site is full of good documentation.

http://spservices.codeplex.com/

Before using the SPServices library, you’ll have to download the jquery.SPServices-0.6.1.js and save it to an accessible location (for this example I added “jquery.SPServices-0.6.1.js” to the SharePoint Site Assets folder on my site) and use the following reference:

        1: <script language="javascript" type="text/javascript" src="https://Server_Name/sites/Your_Site_Name/SiteAssets/Scripts/jquery.SPServices-0.6.1.js"></script>

The best thing about SPServices is that it does all of the heavy lifting for you, saving you the time of coding the Ajax calls and constructing the SOAP envelope.

For an outline of the ‘general syntax’ of the SPServices function I used, refer to the following link:

http://spservices.codeplex.com/wikipage?title=%24%28%29.SPServices&referringTitle=%24%28%29.SPServices&ANCHOR#GeneralSyntax

Lets take a look at how I used the SPServices function:

       1: $().SPServices({

       2:     operation: "Query",

       3:     async: false,

       4:     queryXml: query,

       5:     completefunc: function (xData, Status) {

       6:         xmlProfileResponse = xData.responseXML.xml;

       7:     }

       8: });

Every Web Service call will follow a similar structure with different parameters according to the operation. For example, if you look at line 2 from the snippet above, the ‘operation’ parameter is set to “Query” which indicates to the library that it will be calling the Query Web Service. On line 5, ‘completefunc’ accepts a reference to the callback function that should be executed upon completion of the Web Service call. For this example, I’m setting the response XML to a variable, ‘xmlProfileResponse’ and then parsing it later. Finally, the ‘queryXml’ parameter on line 4 is where the search criteria is defined. Here is the query itself:

       1: var query = '<?xml version=\"1.0\" encoding=\"utf-8\" ?>'

       2:         + '<QueryPacket xmlns=\"urn:Microsoft.Search.Query\" Revision=\"1000\">'

       3:         + '<Query domain=\"QDomain\">'

       4:         + '<SupportedFormats>'

       5:         + '<Format>urn:Microsoft.Search.Response.Document.Document</Format>'

       6:         + '</SupportedFormats>'

       7:         + '<Context>'

       8:         + '<QueryText language=\"en-US\" type=\"MSSQLFT\">'

       9:         + 'SELECT AccountName, Department, WorkId, Description, PreferredName, LastName, Title, Path, MobilePhone FROM SCOPE() WHERE '

      10:         + "(\"DAV:contentclass\" = 'urn:content-class:SPSPeople') "

      11:                      + " AND (\"LASTNAME\" LIKE '%" + lastName + "%')"

      12:         + '</QueryText>'

      13:         + '</Context>'

      14:         + '</Query>'

      15:         + '</QueryPacket>';

As you can see, it’s a straight forward query. In line 11 above I’m filtering by lastName. Notice that each of the values in the Select clause (line 9) come from the User Profile Service’s default fields. The scope is defined by line 10, SPSPeople.

The next step was parsing the results. I chose to parse on the client side by using jQuery and some simple javascript:

       1: function ParseXML(xml) {

       2:     var nameElement;

       3:  

       4:     $(xml).find("Properties").each(function () {

       5:         var oPerson = new Person();

       6:         $(xml).find("Property").each(function () {

       7:             nameElement = $(this).find("Name").text();

       8:             if (nameElement == "PREFERREDNAME") {

       9:                 oPerson.preferredName = $(this).find("Value").text();

            } else {

                if (nameElement == "LASTNAME") {

                    oPerson.lastName = $(this).find("Value").text();

                } else {

                    if (nameElement == "TITLE") {

                        oPerson.title = $(this).find("Value").text();

                    } else {

                        if (nameElement == "PATH") {

                            oPerson.path = $(this).find("Value").text();

                        } else {

                            if (nameElement == "MOBILEPHONE") {

                                oPerson.workPhone = $(this).find("Value").text();

                            } else {

                                if (nameElement == "ACCOUNTNAME") {

                                    accountName = $(this).find("Value").text();

                                } else {

                                    if (nameElement == "DEPARTMENT") {

                                        oPerson.department = $(this).find("Value").text();

                                    }

                                }

                            }

                        }

                    }

                }

            }

        });

    });

    return oPerson;

}

I’m adding the values of the XML response to an object (oPerson), then returning the object and posting back server side (which I’ve omitted).

When working in the sandbox it can be frustrating at times because of all the limitations. However, as you can see this is a very simple technique that allows developers to retrieve data from the User Profile Service despite the limitations of the SharePoint Sandboxed environment.

Full Content Databases Causing Random COM Exceptions in SharePoint 2007

Chris Domino — Fri, 03 Dec 2010 01:48:00 GMT

Aw man it's been a while! My latest project is in full swing, placing me in that doldrum-ish phase when all the new/fun stuff has been figured out and I'm left with coding through the minutia of the requirements. Between that, playing with my new Windows Phone 7 (which is simply exquisite), and working on a pet project on the side, I haven't had much time to write.

As I attack my blog backlog, I'll start with one of interesting discoveries made not by solely by me, but with the guidance and wisdom of my handsome project manager, Matt Schaub, who is this person:

We got a call from our client that they were seeing random errors on the site. Pouring into the ULS logs, we saw not only crazy COM exceptions in general, but specifically, in corners of our code base that had NEVER blown up. Imagine my panic: this is New Balance's intranet! My baby! Over the months of building and testing, we had scrutinously beaten the application into submission at every possible breaking point. There is no way some new logical unhappy path was discovered that eluded our QA efforts and suddenly brought the site to its digital knees!

My contribution to this resolution was noticing that all of the exceptions (and like I said, these were random COM exceptions: different "HResult" codes and meaningless stack traces) were pursuant to code that made updates across the API. It was Matt who suggested that I take a look at the content database. As a good SharePoint architect, I knew to pretend that the content database didn't exist; I never thought to look anywhere near the database server.

But out of options, I obliged him, as you should always do when your PM adoringly offers technical advice. I logged in, and immediately saw that the hard drive on which SQL stored its data on had only a few scarce kilobytes free; the transaction logs were bloated and went into a post-Thanksgiving-like food coma.

Fortunately, SharePoint is smart enough to understand such a situation and put itself into "read only" mode, keeping the site up and running, but disallowing updates (or anything that could potentially increase the size of the database any further). It had the same behavior as if you explicitly marked the database as read only via SQL Server's Management Studio.

So we called New Balance back, and set their DBAs loose on the problem. They truncated the transaction log (turns out the My Sites web application was the culprit, not our app), and configured some other settings to disallow any further unchecked expansion. As soon as the hard drive was freed up, the database was happy, and so was our site.

This was one of those things that was amazingly absent from Bing; how has no one beaten me to this blog topic? Either we were doing was no heinous that it is embarrassing to share it with the world, or I simply wasn't searching well enough. Either way, I hope this saves you from the panic that ensued with us!

The Truth About How Daily SharePoint Alerts Actually Work

Chris Domino — Thu, 26 Aug 2010 17:26:00 GMT

A document changes.

An Email gets sent.

What could be easier?

Well, off the top of my head: open-heart surgery, underwater basket-weaving, and giraffe tooth-brushing to name a few things. SharePoint alerting architecture is a powerful communications tool that provides a convenient mechanism for users to consume information from around the site.

That is, if you don't mess with them.

But of course, we are going to mess with them. We want to control the time, frequency, and appearance of the Emails. The default out-of-the-box settings work, but not quite well enough. All that my client wanted to do was simplify (not go nuts, but simplify ) the standard digest (daily) Email template, and have the notifications shoot out at 9:00 AM. I estimated about a day to do this.

All we had to do was comment out some CAML from the alerttemplates.xml file (located in 12\TEMPLATE\XML) and run an STSADM command, right? Remove the links and columns that they didn't want in the template, and set the time when alerts go out. RIGHT?

WRONG!

To make a story that is longer than it is interesting shorter and more interesting, we went from OOTB alerts to a custom template to a custom handler using IAlertNotifyHandler to alerts not working for a month to users getting Email bombs of duplicate alerts. We went through three different solutions, two different Microsoft support representatives, and one scary spelunk into the SharePoint database. However, we came out safe and sound on the other side, with a cathartic clarity around how SharePoint daily alerts actually work. It wasn't a perfect outcome; there was quite a bit of drama, but a happy client is a happy client.

What I'm not going to do is take you through all the steps required to either customize an alert template, or wire up a code handler to build the Email from scratch (which is what I opted for, since alerttemplate.xml is 10,211 lines long and besides I really like writing code). Someone already did a good enough job of that here.

Instead, I want to provide a high level description of how SharePoint 2007 alerting infrastructure is put together. As I dug though the dumpsters of the Internet looking for any clues to this end, I heard a lot of rumors and false positives and frightening tales. I also came across a new golden nuggets, either from dependable sources, my own research, or the words from Microsoft's mouth itself. So what I'm going to do is simply list out the pieces that work together to make alerts work, having already scrubbed out all the wrong turns I made while traversing down this path.

So here are the truths about daily alerts, in Q & A form...

Which timer job executes daily alerts?

The "Immediate Alerts" job.

Wait isn't that job that runs the immediate alerts?

Yes.

So the one job handles all alert notifications?

Yes.

There is no "Daily Alerts" job?

No.

Promise?

Promise.

Which server physically executes this job?

Officially: All timer jobs run on all front end servers. So any web front end (or indexer, as I've seen) that has the proper assets deployed to it for a particular timer job (DLLs, XML files, etc.) can execute it successfully. Unofficially: not really; even though Central Administration -> Operations -> Timer Job Status reports that the Immediate Alerts job runs on all servers, only one is actually doing the work.

To determine which one, you have to dive into the database. I know. It's ugly; it hurts. Shush. Run the following query against the content database for your web application:



	SELECT * FROM TimerLock

What this does is return the one and only row there will ever be from this table. The two columns are a name of a server, and a date. All we really care about is the name of the server: this is the one that's going to do the notification work. If you want to change it to another server, stop the "Windows SharePoint Services Timer" service on this box, and wait for another server to jump in and acquire this lock.

When do daily alerts get sent?

OOTB, alerts are enabled, and the Immediate Alerts job runs every five minutes. What these runs do is ask the question: Are there any alerts that want to be sent out, but haven't been? All alerts that answer "Yes!" get sent out.

So how do daily alerts know that they want to be sent?

Every alert has a time. For daily alerts, this time defaults to one day (or, more accurately, 24 hours) from the instant they are created. If you create an alert OOTB, you can select an hour on the UI, and the alert will be sent 24 hours from that time. In either case, this "Alert Time" is stored as a real, absolute time, not a TimeSpan.

So every time the Immediate Alerts job runs, it checks for alerts whose time is less than the current time. For each one, it fires the Email, and increments this time by another 24 hours.

What about the job-immediate-alerts property?

All this does is regulates how often the Immediate Alerts job runs. This has no effect if alerts are disabled (the "alerts-enabled" property is set to false). Remember, these properties are specific to a web application.

And what about the job-daily-alerts property?

The main purpose of this property is to confuse the hell out of everyone. This command has been deprecated since SharePoint 2003, but was never removed from the command line.

It has NO effect.

On anything?

NOTHING. Don't ever think about it. Ever.

So in summary?

In summary, alerts store the next time they want to be sent. Every execution of the Immediate Alerts timer job on the server that has acquired the "TimerLock" (for that content database) will send any daily alerts whose time is in the past. Finally, it will increment these times by 24 hours.

Anything else?

Now, there's one other phenomena that I've observed with all this alert stuff: duplicates. And just duplications, but DUPLICATES - as many as a half dozen extra Emails per each unique notification. The most bizarre case we saw was when a user had an alert against a document library that saw five changes in one day, and he received five Emails: one with all five changes listed, one with only the first four, and so on, down to one Email advertising just one change.

What was causing the duplication? The prime suspect was of course the customization of the template, which, admittedly, had a bug, and was broken for some time: there were no alerts for weeks. But eventually I fixed it, and proved it by writing to the ULS logs each time the handler was invoked. And indeed, it was called exactly once for each Email the aforementioned user received. So why was one alert sending out so many notifications?

The most bizarre aspect of this problem was how it was solved, because it solved itself. It was as though the SharePoint alerting infrastructure had a cold: it got worse and worse, barfed, and then started to get better and better. Seriously. My user reported that he got fewer and fewer duplicates each day, until it completely worked itself out and only sent out one notification per alert; each Email containing a list of changes that that document library had experienced over those last 24 hours.

Of course this is unsettling; problems that solve themselves usually have the propensity to start themselves back up. I had a hunch, and I don't blog about hunches. However, I will blog about hunches that Microsoft Premier Support endorses!

<HUNCH>

First, a bit of background: there is another database table that people seem to get their hands dirty with when it comes to fixing alerts: EventCache. What from I can tell, this is the backlog of all changes made to all document libraries. We can then think of alerts as sort of queries into this table. Once an alert gobbles up a change, that change is marked as processed and won't be alerted against again.

Therefore, a daily alert notification is actually the intersection of all unique changes that an alert (which is welded to a document library) "finds." What happens if those changes in EventCache are never processed? They are dangling there, like icicles, waiting to melt back down to the ground. If alerts are broken, these changes seem to just stack up.

Eventually, when alerts are fixed, that stack will topple. It will be like unclogging a drain. However, that's not what happened. The Email duplications diminished slowly, as if each alert could only pull changes from one day at a time. In other words, the alert, when activated by the Immediate Alerts job, doesn't seem to blindly ask EventCache for "all unprocessed changes for this document library" (as I would assume) but rather for "some 24 hour block of changes." Maybe it's that timeframe that gets out of whack, and changes from two different days are processed in the same batch. Or perhaps the logic is flawed, and times aren't updated properly if the notification system is malfunctioning due to a bug somewhere in the template customization.

It still makes more sense to me that, once repaired, all notifications will be shot out in the next batch. Furthermore, I think it's counterintuitive that "old" changes should be notified at all. If a user hooks up an alert, they want new information - new content. The apropos availability of old news isn't new news.

</HUNCH>

Each day as the alerts were "worsening" and then "healing" themselves, my client user forward me all the Emails he got. So did another user, who only had one alert, and only got dups sometimes. The point is that there were no discernable patterns. I poured over the frequencies among alerts, number of Emails, and number of changes in each Email, but came up with nothing. I spent hours digging though verbose ULS logs, only to further validate that my custom handler was called exactly once per whatever it was that SharePoint was detecting as a notification.

When my Microsoft rep backed up the above hunch, I was encouraged, but not satisfied. Unfortunately, this remains a mystery to this day. Microsoft closed the case without any more discussion. My client closed the bug without any more discussion. It's like everyone but is happy that this one little bug - which was only supposed to take a day to implement - has magically disappeared.

Well it's time for me to join their ranks, as there is no more time, money, calories, or sanity to invest into the duplicate alert issue. Usually my posts have happy endings, but alerts are emo like that. If anyone out there has any ideas, please don't hold back. Hopefully I was able to at least help a little bit in terms of cracking open the black box of enigmatic SharePoint 2007 daily alerts.

InfoPath Browser Enabled Forms and Crossing Web Applications

Jeremy Williams — Fri, 13 Aug 2010 18:09:15 GMT

Scenario:

A browser-enabled InfoPath form was to be built that allowed users to fill out a form, email it to themselves, attach a document to be uploaded to SharePoint, and then sent to an individual that understands SharePoint. Sure, the easy answer here is to make the user upload the file directly and just classify it there. The problem is that many users are unwilling to be trained on SharePoint, so this was elected as a compromise to fully utilizing SharePoint. There’s some other border-cases that this form solves, but this is neither here nor there.

Challenge:

The form has a number of drop-downs in it, some are SharePoint ‘choice’ fields, and two are SharePoint ‘lookup’ fields. The choice fields all function just fine since I’m using a nice little XML file to specify those dropdowns (they rarely change and it’s much quicker to load than querying all of the lists). The lookup lists do need to be refreshed on each form load, since those are subject to additions. However, InfoPath Browser forms have a nasty habit of ordering SharePoint-list-data source values by ID rather than Title. [To add further insult to injury, the full-blown InfoPath client orders by Title..] Users wouldn’t go for that on lists that contain upwards of 500 choices, so I had to find a way to order by Title…

After reading some great articles on using owssvr.dll to get a XML output for a particular list, I figured I had the problem licked. This method would allow me to return live data (on form-load), required no code-behind, and seemed straight-forward. So I followed the instructions (http://blogs.msdn.com/b/infopath/archive/2007/01/15/populating-form-data-from-sharepoint-list-views.aspx), and then pressed enter to get a plain-white IE window (no XML as promised). After verifying that this wasn’t some obscure browser setting, I looked at the lists I was referencing and they were (both) custom lists that also had lookup columns contained within. I then suspected that the lookup column (especially one that allowed multi-select) wasn’t supported by the owssvr.dll method. Luckily for me, we are running a nifty little master-list data synchronization on this environment. The custom code basically reads a list (considered the ‘master’) on Web Application A, Site Collection A, and then writes any add/update/delete actions to copy-lists stored other Site Collections under Web Application B. Anyways, the ‘synchronized’ lists don’t contain the lookup columns, just the ‘ID’ and ‘Title’ values. Effectively, this allowed me to test owssvr.dll reading a ‘simple’ list…

After running a quick test, I discovered that owssvr.dll worked famously with the sync-lists! So, I rebuilt my form data connections, redeployed the form, and then BAM! Yet another error about SharePoint not being able to access data sources [Error ID 6932](and all of my dropdowns of lookup lists were blank). After some poking around, I surmised that InfoPath form services (even with cross-domain enabled) doesn’t like crossing SharePoint web applications, even though the user account I was using had permissions to both web applications.

Fix…Workaround:

So, to get the form to play nice, I simply deployed my form and associated data sources in a site under Web Application B. By doing this, my owssvr.dll XML files could reference the appropriate sync-lists correctly and in the same web application. After I did this, the form worked as advertised and I simply changed all of the applicable links to point to the new form location.

I realize that this is a fairly unique scenario, but I think there are a couple of important takeaways. First of all, for users that are running into the blank-white IE screen when using owssvr.dll, hopefully this post helps you in your test cases by trying the method after removing lookup columns. And Second, for those who might be considering/trying to get InfoPath Browser Forms to cross web applications, realize that you may have to somehow provide a simplified version of your list-data.

At the end of the day, the form worked as advertised, and the correct columns were returned (and ordered).

Customizing People Search Results in MOSS 2007 – Part 3 of 3 – Search Results Customization

Jeremy Williams — Mon, 14 Jun 2010 18:51:28 GMT

This is the third and final post of a three part series, if you missed it, here’s Part 1 and Part 2. This post will go into the details of consuming the managed properties we configured last time around, and then displaying them in our search results.

As a review, here’s where we are:

User Profile Properties Changes
SharePoint Search Changes
Search Results Page Customization

Add Managed Properties to List of Columns to Query

The first step to displaying your newly added managed properties in the search results is make sure they’re being returned as part of your result-set! To do this, navigate to the people search result page on your Search site. A quick and easy way to do this is to run a search (using the ‘People’ scope) for your own name. Once you’re on the search page, go ahead and edit the page. Once you have the page in edit mode, click on the context menu for ‘People Search Core Results’ and select ‘Modify Shared Web Part’. On the pane that appears to the right, go ahead and expand the ‘Results Query Options’ Group, then click the text box under the ‘Selected Columns’ heading; and finally, click on the button with the ellipsis (…). This will pop up a text editor. To prevent yourself from going a little crazy, I highly recommend editing this text in something else, like Notepad/Wordpad/your favorite IDE/etc. You will want to add a line (below) for each of your newly added custom managed properties.

<Column Name="YourManagedPropertyNameHere”/>

In the screenshot below, you can see that I’m adding my ‘StreetAddress’ managed property:

Once you’ve added all of your properties, go ahead and paste your XML back into SharePoint pop-up text box and click ‘Ok’ on the web part property pane to save your changes. Now, your custom property is available to and for our final step…

Reference columns in custom XSLT

Now that the people search core results web part is properly returning your managed columns, you’ll want to customize it’s XSLT (style sheet) to include the newly added column(s). Same as last time, I highly recommend you edit this XSLT in your favorite IDE, as it’s really painful to work with code in SharePoint’s popup text-editor. Anyways, to access the XSLT, go ahead and click ‘Modify Shared Web Part’ on the People Search Core results web part, and click the ‘XSL Editor…’ button.

The XSLT sheet that ships with SharePoint is about 360 lines long, and there’s a couple of places you’ll need to add your column(s). For the example, I’m simply going to stick in the ‘StreetAddress’ field after a user’s title, department, phone, and office. Certainly, you can do much cooler things here with the XSLT, but I’ll save that for another day. The first place you’ll need to add your column is around line 137. In my example below, I have established my XSLT variable for StreetAddress as ‘street’ (mainly to illustrate the naming differences).

Important Note: in the ‘select’ value, be sure to use ONLY lowercase text; if you do capitalize names here, you run a very high risk of the proper field not being returned.

The next place to add the property is around line 337, as shown below:

And finally, I’ve added an XSL if-block with street around line 355:

Doing this will yield the following results:

Before:

After:

Final Thoughts

Clearly, the trickiest part of this process is the XSLT customization, which is why I’ve chosen to show you how to simply add a property to the XSLT. You can do all kinds of cool things with XSLT, such as return the users in a grid pattern with key information beneath their picture, or return people with a contact-card styling, the list is as long as your imagination.

Thanks for sticking through all three posts with me; I hope this helps clear up any confusion on the whole process.

Errata

Random Error

Sometimes, SharePoint will throw a false error at you after clicking ‘Ok’ to web part changes. The error looks something like this:

If you do come across this, simply check in your page and then click in the URL bar and press enter (don’t just refresh the page). If you still get the error after that, you’ve most likely made a coding error in your XSLT.

Field Not Displaying

If your field isn’t returning, and you’re fairly confident that you’ve written valid XSLT and added/configured/mapped all your properties correctly, you might need to refresh your user profiles. To do this, initiate a full import on your people profiles in SharePoint. Once the full import has completed, start an incremental search crawl to pick up these changes. Once complete, go ahead and run your people search again and your field should now appear:

Example of Missing Field (notice the hanging ‘-' after ‘Downtown’; this is where Street Address should be:

Example of the Missing Field existing as expected:

Customizing People Search Results in MOSS 2007 – Part 2 of 3 – Search Configuration

Jeremy Williams — Wed, 09 Jun 2010 18:36:00 GMT

This is the second post of a three part series, if you missed it, here’s Part 1. This post will go into the details of taking the User Profile Properties we created the last time around, and making sure that they’re available to us in Search.

As a review, here’s where we are:

Run an incremental crawl

If you haven’t already, be sure to run a full import on your user profiles (This should be done after you’ve added all your custom profile properties from step one) Assuming that a full import has run, the next step is to run a crawl on whatever content source is crawling people. 9 times out of 10, this would be the ‘Local Office SharePoint Server Sites’ content source. This can be done by going to your Search Administration page, clicking on ‘Content Sources’ then selecting ‘Start Incremental Crawl’ from the ‘Local Office SharePoint Server Sites’ context menu.

After the crawl has completed, it should have picked up all of your newly defined user profile properties as a crawled property. Next, we’ll want to use those newly crawled properties in the creation of our managed properties. The managed property will (ultimately) be used to return information about a user in the search results.

Add mapped profile properties as managed properties

To create a new Managed Property, navigate to your SSP management page. From there, click on Search Administration, and then click on ‘Metadata properties’. Once at the Metadata Property Mappings window, click on the ‘New Managed Property’ link, which will take you to a screen similar to the one shown below:

This is where you will be defining the name (to be used in search) of all your people profiles. Personally, I like to use the same name as that returned by the crawled property. This is due to the fact that I handled the naming of the property when I created it. It simply makes life easier to remember only one property name that to track the property through all phases (AD, Profile Property, Crawled Property, Managed Property, XSLT variable). In the screenshot above, I have created a managed property for Street Address. Assuming you’re following my advice above, you will use the same profile property name for naming the managed property. In my example, this yields a Property name of: “StreetAddress”. Filling in a description is strictly optional, I have elected not to do so in my example. Be sure to leave the ‘Text’ radio button checked, as this will act as a filter on crawled property search we’re about to run. [Obviously, if you’re adding a crawled property that is an integer value, be sure to change this radio to reflect as such] Next, you will need to click ‘Add Mapping’ to select the crawled property(-ies) referenced by this managed property. In my example, I know that I named by Profile Property ‘StreetAddress’, so I’ll search for ‘Street’ in the dialog:

This is an easy one, as only 1 result was returned. Generally speaking, if you get more than 1 result, be sure to select the result prefixed with ‘People’. Click Ok and you’ll return to the ‘New Managed Property’ Screen. The remaining options shouldn’t impact us, so you can leave them alone. Go ahead and click Ok. Voila, you’ve created a Managed Property for StreetAddress, bringing you one step closer to your customized People Search experience. Repeat as necessary for all of the properties you’ve added to User Profiles.

Run an incremental crawl

When you’re finished adding all of your new Managed Properties, you’ll need to run an incremental crawl. Disclaimer: Most (if not all) Microsoft documentation claims that you have to run a full crawl at this point. I’ve only had to do that once for people profiles and their associated metadata properties; typically, the incremental crawl works for me. The purpose of this crawl is to ‘pick up’ all of your newly update managed properties. Once you start this crawl, go ahead and get yourself a cup of coffee and marvel at your SharePoint prowess!

That wraps it up for the second step of the process. I hope to have the third and final post up soon, so stay tuned!

Customizing People Search Results in MOSS 2007 – Part 1 of 3 – User Profile Properties Change

Jeremy Williams — Tue, 25 May 2010 15:03:00 GMT

One of the niceties (at least for us implementer-folk) of SharePoint’s search is that both the content and display of the result page can be changed with a few tweaks to some the profile sync process, managed properties, search query result web part properties, and the result XSLT. Okay, so I’ll admit, it isn’t the most straightforward process, but it’s still pretty cool that this can all be accomplished without any custom code! If you have liberal definitions of “out of the box SharePoint functionality” like I do, then you’re in luck. Everything we’ll be going through here can be considered Out of Box!

Alright, so this post-series will be fairly detailed, therefore it will be broken up (for both author and reader sanity) into three parts:

User Profile Properties Changes
SharePoint Search Changes
Search Results Page Customization

For those of you that have done any searching on the subject, you will find a decent amount of custom people search XSLT result sets out there. However, what you’ll struggle to find is an end-to-end instruction set to fully implement a customized people search experience. I know it’s a lofty goal, but I hope this series of posts can help you get from zero to your custom people search experience. At the very least, it should get you pretty close!

So here’s the process that we’ll be going through:

If you are only going to use the 21 or so default mapped properties, feel free to skip ahead to the second post. Again, this first part is only required if you have non-standard user properties that you would like to display in People Results. My favorite example of a non-standard attribute is the ‘Mobile Phone’ value. In most AD implementations, a standard user account will not be able to ‘read’ this attribute into SharePoint’s user profiles. In order to properly access these properties, work with your AD administrator to secure a Profile Import Account with the correct level of access. Basically, the account will need the ability to read each of the fields that you’re working to import. I’m not going to dive into the details of setting up the correct permissions in this series, perhaps in the future I’ll tackle that subject. In the meantime, if (and only if) you’re in a test environment, the easy solution is to use a Domain Administrator account; please do not do this in your production environment.

To change this account, navigate to the Shared Services Provider (SSP) that you’ll be working on (you may have a direct link and/or it’s accessible from Central Administration). Once on the SSP homepage, click the ‘User Profiles and Properties’ link. From the next page, you will want to click on the ‘Configure Profile Import’ link. From the following page, select the ‘Specify Account’ radio button in the ‘Default Access Account’ heading and enter in the credentials for your elevated account.

The next step in the process is to add whatever additional fields you need to the ‘User Profiles and Properties’ area. To do this, navigate to SSP homepage, and click on the ‘User Profile Properties’ link. Near the bottom of this window, you will see a heading called ‘User Profile Properties’; click on the ‘Add profile property’ link. This will bring you to the form shown below. If you’re looking to display the ‘mobile’ attribute (or whatever value you’re adding here) to all employees, feel free to mirror the settings in the screenshot below. If not, tweak the settings to your liking.

The hardest part of this form is the dropdown near the end where you actually select what Active Directory field you will be mapping to. These field names are not necessarily intuitively named. For example, city is called ‘l’. To get an idea of what field you’re looking for, go ahead and and fire up ADSI Edit and connect to your favorite domain controller. From here, you’ll want to navigate to an OU that contains a User Account with the property that you’re looking for. Once you find the user account, go ahead and right click on it, and select properties. This will bring you an exhaustive list of that object’s AD attributes. Go ahead and find the property you’re looking for and then select that property in SharePoint’s Add User Profile Form. Be sure to note the AD-names of all properties that you add as you’ll need this list later.

After clicking OK and repeating this process for all of the non-standard fields you want to import you should be ready to move on to the next post, which I’ll finish up in the next couple of days.

Building a Better SPGridView

Jonathan Rupp — Tue, 30 Mar 2010 18:15:00 GMT

Sometimes with SharePoint customizations, you run into a scenario where you want to do something that is “just like this OOTB thing, but a little bit different.” Sometimes, that turns out to be trivial. Sometimes it turns out to be a fair amount of work to get what you want. SPGridView is one the latter – sounds great, but takes more work than I’d like to be at feature-parity with the less generic components.

Recently, I had two different projects that wanted something that looked like a ListViewWebpart, but had a more complex data source than a simple view on a list (both involved fetching data from multiple sites within the site collection and joining it to a couple of other lists). Seems simple enough, right? Fetch the data needed from all the source lists (and/or cross-site queries via SPSiteDataQuery) into custom objects, join them together via LINQ-to-Objects, stick the results in a DataTable, display it with SPGridView, and off to the next task, right? Well, yes. It does look right, but sorting and filtering don’t work. Even when you add ObjectDataSource to the mix, there are issues with sorting and filtering getting in each other’s way.

After a bit more digging online, I found a few sources that pointed me in the right direction of what I’d need to do to make it all work:

With these, plus a bit of tinkering, I got it to work like my first client wanted. However, I had to do a lot more work than I wanted to make it happen – until the last piece was in place, it wouldn’t work quite right. Two weeks later, I had another client ask me for almost the same thing (obviously, the data involved was quite a bit different, but the basic idea was the same – custom data fed into a table that looks like a normal SharePoint one). Since I’m a heavy opponent of “reuse by copy and paste”, I thought I’d separate out the “fixes” to the SPGridView from the particulars of this implementation and build a control I could use in the future when this kind of scenario came up.

In my mind, the developer wanting to use this control should only have to provide the information relevant to the problem domain (data, columns) and leave the implementation details (wiring sorting/filtering to work and work together) up to the control. To that end, I present SmartSPGridView:


    1 using System;
    2 using System.Collections.Generic;
    3 using System.Text;
    4 using Microsoft.SharePoint.WebControls;
    5 using System.Web.UI.WebControls;
    6 using System.Data;
    7 using System.Web.UI;
    8 
    9 namespace SPGridDemo
   10 {
   11     /// <summary>
   12     /// Wraps up everything needed for automatic sorting and filtering.
   13     /// Heavily based on:
   14     ///   http://www.reversealchemy.net/2009/05/01/building-a-spgridview-control-part-1-introducing-the-spgridview/
   15     ///   http://www.reversealchemy.net/2009/05/24/building-a-spgridview-control-part-2-filtering/
   16     /// Triggering binding is left up to the parent control -- call GridView.DataBind() -- GetData event will be raised for you to supply the data.
   17     /// Also http://vspug.com/bobsbonanza/2007/07/02/filtering-with-spgridview/
   18     /// </summary>
   19     public class SmartSPGridView : WebControl, INamingContainer
   20     {


   21         public SmartSPGridView()
   22         {
   23             // initialize the ObjectDataSource and SPGridView, wire them together and hook in the needed event handlers
   24             DataSource = new ObjectDataSource()
   25             {
   26                 SelectMethod = "SelectData",
   27                 TypeName = this.GetType().AssemblyQualifiedName,
   28                 ID="DS",
   29             };
   30             GridView = new SPGridView()
   31             {
   32                 AllowSorting = true,
   33                 AllowFiltering = true,
   34                 AutoGenerateColumns = false,
   35                 FilteredDataSourcePropertyName = "FilterExpression",
   36                 FilteredDataSourcePropertyFormat = "{1} = '{0}'",
   37                 ID="view",
   38             };
   39             GridView.DataSourceID = DataSource.ID;
   40             DataSource.ObjectCreating += new ObjectDataSourceObjectEventHandler(DataSource_ObjectCreating);
   41             DataSource.Filtering += new ObjectDataSourceFilteringEventHandler(DataSource_Filtering);
   42             GridView.Sorting += new GridViewSortEventHandler(GridView_Sorting);
   43             GridView.RowDataBound += new GridViewRowEventHandler(GridView_RowDataBound);
   44         }
   45 
   46         public SPGridView GridView { get; private set; }
   47         public ObjectDataSource DataSource { get; private set; }
   48


   49         /// <summary>
   50         /// Add filter header pieces
   51         /// </summary>
   52         void GridView_RowDataBound(object sender, GridViewRowEventArgs e)
   53         {
   54             if (sender == null || e.Row.RowType != DataControlRowType.Header)
   55             {
   56                 return;
   57             }
   58 
   59             SPGridView grid = sender as SPGridView;
   60 
   61             if (String.IsNullOrEmpty(grid.FilterFieldName))
   62             {
   63                 return;
   64             }
   65 
   66             // Show icon on filtered column
   67             for (int i = 0; i < grid.Columns.Count; i++)
   68             {
   69                 DataControlField field = grid.Columns[i];
   70 
   71                 if (field.SortExpression == grid.FilterFieldName)
   72                 {
   73                     Image filterIcon = new Image();
   74                     filterIcon.ImageUrl = "/_layouts/images/filter.gif";
   75                     filterIcon.Style[HtmlTextWriterStyle.MarginLeft] = "2px";
   76 
   77                     // If we simply add the image to the header cell it will
   78                     // be placed in front of the title, which is not how it
   79                     // looks in standard SharePoint. We fix this by the code
   80                     // below.
   81                     Literal headerText = new Literal();
   82                     headerText.Text = field.HeaderText;
   83 
   84                     PlaceHolder panel = new PlaceHolder();
   85                     panel.Controls.Add(headerText);
   86                     panel.Controls.Add(filterIcon);
   87 
   88                     e.Row.Cells[i].Controls[0].Controls.Add(panel);
   89 
   90                     break;
   91                 }
   92             }
   93         }
   94


   95         void GridView_Sorting(object sender, GridViewSortEventArgs e)
   96         {
   97             // sorting loses the FilterExpression, so we have to restore it
   98             if (ViewState["FilterExpression"] != null)
   99             {
  100                 DataSource.FilterExpression = (string)ViewState["FilterExpression"];
  101             }
  102         }
  103 
  104         void DataSource_Filtering(object sender, ObjectDataSourceFilteringEventArgs e)
  105         {
  106             // save the filter expression built when we add a filter, so we can restore it when sort blows it away
  107             ViewState["FilterExpression"] = ((ObjectDataSourceView)sender).FilterExpression;
  108         }
  109 
  110         protected override void LoadViewState(object savedState)
  111         {
  112             base.LoadViewState(savedState);
  113 
  114             // clear the saved filter so we don't restore it if the user sorts
  115             if (Context.Request.Form["__EVENTARGUMENT"] != null &&
  116                  Context.Request.Form["__EVENTARGUMENT"].EndsWith("__ClearFilter__"))
  117             {
  118                 // Clear FilterExpression
  119                 ViewState.Remove("FilterExpression");
  120             }
  121         }
  122


  123         void DataSource_ObjectCreating(object sender, ObjectDataSourceEventArgs e)
  124         {
  125             // called by the ObjectDataSource to create an instance of this object
  126             e.ObjectInstance = this;
  127         }
  128 
  129         protected override void CreateChildControls()
  130         {
  131             // add the ObjectDataSource and SPGridView as children
  132             base.CreateChildControls();
  133             this.Controls.Add(DataSource);
  134             this.Controls.Add(GridView);
  135         }
  136 
  137         protected override void OnLoad(EventArgs e)
  138         {
  139             base.OnLoad(e);
  140             this.EnsureChildControls();
  141         }
  142 
  143         public DataTable SelectData()
  144         {
  145             var e = new GetDataEventArgs();
  146             OnGetData(e);
  147             return e.DataTable;
  148         }
  149


  150         #region GetData event+args
  151         public class GetDataEventArgs : EventArgs
  152         {
  153             public DataTable DataTable { get; set; }
  154         }
  155         public event EventHandler<GetDataEventArgs> GetData;
  156         protected virtual void OnGetData(GetDataEventArgs e)
  157         {
  158             EventHandler<GetDataEventArgs> eh = GetData;
  159             if (null != eh)
  160             {
  161                 eh(this, e);
  162             }
  163         }
  164         #endregion
  165     }
  166 }

Basically, it’s a UserControl with an ObjectDataSource and SPGridView wired together and with the events needed to get full sorting/filtering working already in place. To use this, all you have to do in your webpart is:

Create an instance of SmartSPGridView
Hook the GetData event and supply the DataTable
Call DataBind() at the appropriate time (OnPreRender works well)
Configure and add the view to your webpart (usually in CreateChildControls)
- Add the columns
- Populate the FilterDataFields property
- Add the view to the webpart’s Controls collection

ObjectDataSource makes sorting work, FilterDataFields makes filtering work, and several event handlers keep them from tripping over each other. And, I don’t have to keep fighting the same battle every time I need this kind of solution for a project. Now, I’m off to pick another fight with Sharepoint.

The downloadable version of the code is linked below.

Datasheet View Extras – Who Knew?

Jeremy Williams — Mon, 15 Mar 2010 16:40:18 GMT

I often tell my clients that I learn something new about SharePoint everyday, and (today) I have the perfect anecdote to prove it! For those that have already found the sweet toolbar on the datasheet view, the rest of this post may be a bit boring to you; however, if you haven’t found the datasheet view task-pane, read on!

Recently, I was working on some list items in datasheet view on SharePoint 2007, and I accidentally clicked on the little right arrow on the right side of the datasheet view:

Much to my surprise, this handy-dandy little task-pane came zooming out:

While the task-pane doesn’t offer any earth-shattering features, it’s still a handy little tool. The undo feature is nice to have around, as was the sort option (much easier/quicker than clicking all of the header in an attempt to get the perfect sort). Also, the ‘Clear Filters’ button was handy as well, and stopped my previous habit of refreshing the browser to get back to a clean-slate on the data sheet viewer.

SharePoint 2007 Search Administration: Scheduling and the UI

Jeremy Williams — Fri, 19 Feb 2010 18:40:00 GMT

As an SSP administrator, one can control and tweak the many aspects of SharePoint Search. One piece of the puzzle an admin can configure is a content source. For the uninitiated, a content source is simply a location where SharePoint Search is going to go out and look for files. Some examples of content sources could be all of your SharePoint sites, a file share, or even your public website. When configuring a content source, an administrator must choose how often that source will be crawled.

There are two types of crawls, a full crawl and an incremental crawl. While there is an (almost) infinite number of schedules one could set up for their content source, I often see a full crawl happening relatively infrequently (once a week or month, depending on content size), and incremental crawls happening quite frequently (every 5-60 minutes). Why? Let’s say a user uploads a file to SharePoint and tells their buddy, “Hey, I just uploaded the document about Client ABC to SharePoint, go check it out!” Their buddy (since he doesn’t know where the file is located) goes right to his trusty SharePoint search box and searches for “Client ABC”. If an incremental crawl hasn’t run since the file was uploaded, then it won’t appear in the results. This in turn makes for frustrated users, and an all around ‘bad’ SharePoint experience [but alas, I digress..]

Back to the point, when scheduling an incremental crawl, here’s a fairly typical starting point (picture below):

Everything seems to make sense in there, except for the last two text boxes. One way to interpret that section is, “Repeat the incremental crawl every 15 minutes and allow it to run for 1440 minutes”. Based on this interpretation, one may be lead to believe that an incremental crawl could start and run as long as 1440 minutes (that’s 1 full day). Well, as an SSP admin, I would hate for there to (potentially) be 1 crawl each day, so I’m going to change that 1440 to 20. Great, I’ve got crawl set up and my users should always be able to find their files (relatively) quickly, right?

Sadly, the answer is No. That text is actually interpreted as, “Repeat the incremental crawl every 15 minutes, and continue crawling every 15 minutes for 1440 minutes.” So, in my example above, the text becomes, “Repeat the incremental crawl every 15 minutes continue crawling every 15 minutes for 20 minutes.” This will yield you exactly 2 incremental crawls everyday, one around midnight, and the other around 12:15…After that, you’ll have to wait until midnight rolls around again.

For some users, this might have been a “duh” type of post because they interpreted the text and control in the manner Microsoft intended. However, other users may have incorrectly interpreted the text/controls as my example pointed out…

MySites and Quotas: The Nuances

Jeremy Williams — Tue, 16 Feb 2010 18:15:00 GMT

Site Quotas in SharePoint 2007 are a great tool, but they can sometimes be misunderstood. One of the most common confusions with quotas comes with their interaction with MySites. MySites (IMHO) are a great feature of SharePoint 2007, and are only getting better in SharePoint 2010. However, the adoption of MySites in many organizations is organic and unplanned. Right around the time that MySites near critical mass, the desire to wrap some additional governance around the sites crops up. Arguably, one of the most obvious governance tools for MySites is a Site Quota. So the governance committee decides on some thresholds and passes the implementation down to their Farm Administrators…

Let’s put on our ‘Farm Administrator’ hat…

I need to enforce a Personal Site quota on my users, so I’ll just set up the thresholds on the Personal Site quota template, and apply that to MySites. After that, everyone now has that quota, right? Wrong!

Okay, so that didn’t work and now I’m getting yelled at because users are uploading their personal photo and music collections to their MySites, thereby eating up all the space on our SAN. Since editing the quota template didn’t do the trick, let’s go ahead and create a new template and apply that to MySites. Alright, now everyone has that quota right? Wrong Again! [Aside: Remember, you can always block certain file extensions from ever being uploaded to SharePoint in Central Administration.]

Darn it SharePoint, you’re really raining on my parade, what am I doing wrong?!?!

Like many really annoying problems, this boils down to semantics…Quotas are called ‘Quota Templates’ for a reason, they are a template, and act just like a site template would. After applying a template, if I make a change to the template, all new sites using the template will take the new values; but the old sites will remain static. Here’s a laundry list of nuances, and a quick demo/proof of this behavior:

To reliably change the quotas of MySites, don’t create a new template, you’ll just want to edit the Personal Site Template. I’m not saying that you can’t create your own templates, but why work harder if you can work smarter?
Quotas act like site templates; they’re a snapshot…So if I make site A when personal site quota = 10/8; then I change the quota to 50/40 and create site B, site B quota = 50/40, site A quota = 10/8
Don’t always rely on Central Admin to tell you the truth about site quotas and what a particular collection’s quota is; instead use the stsadm –o enumsites command. Screen-cap below:

- Administrator was a manually set quota
- Test1 was using the initial Personal Site Template Quota
- Then I changed the Personal Site Template Quota, did an iisreset for good measure, and made test2’s MySite.
- So Test 1 and Test 2 used the same template, however they have different values since the template was different during each site’s respective build-time.

At the end of the day, the best approach is to properly plan for MySites and enact a reasonable quota template right from the beginning. If that isn’t an option, you can customize (or search for other’s customizations/extension) stsadm.exe to iterate through MySites and manually apply your new template.

Living in the Social Media Age: Are You?

jwillinger — Mon, 11 Jan 2010 23:20:00 GMT

Living in the Social Media Age: Are You?

More than 56% of marketers plan to incorporate social media into their businesses next year, according to a recent survey by the Center for Media Research.

With so many social media channel options to choose from, which one do you use for your marketing communications strategy?

In July 2009, Russell Herder and Ethos Business Law study of national business leaders highlighted that the most popular social media channels were the following:

Facebook (80%)
Twitter (66%)
YouTube (55%)
LinkedIn (49%)
Blogs (43%)

In my first blog post, my audience confirmed that Facebook and Twitter were the most popular social media platforms. So, as a marketer, should I use the most popular social media channel or a combination of both? Well, the short answer is that it depends. Since each tool works in a different way and with the social media landscape changing everyday, the key is to find out what your targeted audience likes to use.

The bottom line is that you need to be a part of A conversation because these conversations are happening, whether you are in the social media game or not. My next post will be focused more around SharePoint as that platform for an enterprise to build that social computing platform upon.

401 Reasons Why SharePoint Web Services Don't Work Anonymously

Chris Domino — Thu, 07 Jan 2010 07:43:00 GMT

<RANT>

I am always weary of using third party controls in my solutions. I feel that the risk of slightly reinventing the wheel is much less severe than that of getting to the end of project and realizing that some minor requirement that the control in use doesn't support will become a show stopper. When you don't have 100% control over your functionality (or the time/budget to customize open source code) then you had better make damn sure your third party components either FIT PERFECTLY or that your client won't mind cutting features.

That's why when I party with SharePoint, it's always "first party." Who wants to go to a third party when the first party is way cooler?

</RANT>

That said, I ran into such an issue in my last project. We were using a third party tool that, at the 11th hour (or, more accurately, around 9:45) immediately failed when we were informed that its SharePoint site had to be anonymous. Now our client probably pushed this requirement to the back burner because the functionality of this component had nothing to do with authorization. (I am purposely not going to share which component it is, because, well, I'm not a douche.)

The problem is that OOTB SharePoint web services, at least the ones this web part was calling, do not support anonymous access. The two in question here are SiteData.asmx and List.asmx. However, the depth of this unsupportedness far exceeded my expectations - as you'll see.

The client first noticed the problem when "random pages" would challenge for credentials exactly twice, which is of course two more times than an anonymous site should challenge anyone. These random pages were of course the ones containing the web part in question. So I fired up Fiddler and immediately saw the two 401s resulting from calls to the aforementioned web services.

"Easy fix," I thought as I remoted into the server and fired up IIS. Once there, I navigated to the web site corresponding to the web app in question, expanded it, and set the _vti_bin virtual directory to anonymous, using the app pool identity for impersonation.

And shazzam, no more challenges!

Now the next day, heading to the status meeting, I prepared myself for praise and glory resulting from my victory over yet another third party control's nonsensical way of doing things. I mean, come on! This is a web part; this is server side code. ALWAYS. Why call the web services? Why not just use the API? If this was our code, I could just fix it, or at least have an arch-to-arch heart-to-heart and inquire as to why this was the chosen method, as there could have been some weird requirement or dependency of doing things that way.

But I'm a consultant. Every project is an edge case in some way. That's why third party controls fail me so often.

So I sat down at the meeting, and was immediately informed that, despite the lack of challenges, there was still "something wrong" with the web part. It was scarcely noticeable, but still not right. So I went back to Fiddler, and indeed saw that 401s were still being returned. Looking into the raw HTTP, I noticed that only one line of text was being returned: "401 UNAUTHORIZED."

I then flipped _vti_bin back to Windows auth, and saw the challenges again. Back in Fiddler - and here's the interesting part - I saw the familiar markup of IE's default 401 error page! This makes sense; IIS wants windows credentials, IE didn't give it any, so it returns a 401, and the web service call fails and dies quietly.

But when anonymous is set, we get that one line message: "401 UNAUTHORIZED." Obviously, this is not coming from IIS. My only guess, after going through the trouble of Reflecting what I could of Microsoft.SharePoint.dll, is that code inside the web method sends this response if the current user is not authenticated, regardless if it's virtual directory is set to be anonymous. Here's what I dug up in Reflector:

Note: I couldn't get the actual web service code loaded into Reflector, so I can't be sure about this assumption. I tried OWSSVR.dll, which lives in the ISAPI folder in the SharePoint hive, but Reflector couldn't load it since it does not contain a CLI header.

So that's a dead end: it appears as though the OOTB SharePoint web services explicitly send 401 responses even if their virtual directory is set to be anonymous. This is certainly, IMHO, another knock against using them for anything server side. Maybe that's why it was so hard to get them to work in InfoPath 2003...

However, SharePoint 2010 is upon us! Next step: see if this is still an issue in the new product.

Stay tuned!