idubbs.com

The following update apparently slipped under my radar a few weeks ago:

October Cumulative Update:

To learn about the issues that are fixed in this update, see
Description of the SharePoint Server 2007 hotfix package (Coreserver.msp): October 28, 2008 (http://go.microsoft.com/fwlink/?LinkId=133374&clcid=0×409) and
Description of the SharePoint Server 2007 hotfix package (Coreservermui.msp): October 28, 2008 (http://go.microsoft.com/fwlink/?LinkId=133376&clcid=0×409).

Microsoft.SharePoint.portal.dll version number: 12.0.6331.5000

I usually rely on the SharePoint Team Blog for updates like this, but didn’t see one come across this time. 

A few notes from the hotfix description pages:

• “When you search for more than 9 digits but less than 40 digits, you may not receive the expected search results”.  Hmm.  That seems like kind of a sweet spot in SharePoint’s search functionality.  I haven’t seen this anywhere in the wild - anyone? 
• I had several people at the MNSPUG yesterday mention issues they were seeing with the spell-checker in SharePoint.  The coreservermui.msp version of the October Updates contains a few spell-check related fixes that might be relevant.   

Just a quick note while playing with the My Profile page this evening…

I’ve been bringing up the My Sites and Profile pages for some time now with clients, trying to get more folks to start using them in their environments when appropriate because in general these pages are very useful, but underused.  When I do show them what is available there are varied reactions to seeing what can be done on these pages, but inevitably someone doesn’t like something or other and wants to remove web parts from the page.  I distinctly remember a few folks not liking the Memberships web part showing the distribution groups they were in because of sensitivity within their staffs regarding to who’s being included and who’s not - that lovely politics game.  :)  Anyhow, what I hadn’t realized at the time was that managing the Membership web part is REALLY EASY.  You simply click on the web part header or click the ‘Manage Memberships’ link (who would have guessed…) below the listing and you are able to set the privacy setting for each item as needed.  Pretty slick, though a little different from what many SharePoint users are used to with day to day permissions and lists. 

See.  Nice and easy… Now back to work. 

Note: This post got a lot longer than I anticipated - even without screenshots - and because I don’t want to lose you before you get to what I consider the good stuff, I have it labeled as such below and you can jump right to it if you want.  In order to provide what I consider a more complete story however, I feel obligated to provide a little foundation first for those that are interested. 

The background / foundation:
As part of setting up a SharePoint (MOSS) environment, administrators need to configure the Profile Import in SSP in order to get user accounts from Active Directory into the SharePoint Profile database.  By default, SharePoint will import all users from the Current domain - which is not always the desired list of accounts. 

To change the accounts that are being imported, you can do the following:

1. From the Shared Services home page, select User profiles and properties
2. Select View import connections
3. Hover over the name of your connection and select Edit
4. The Search Settings section of the Edit Connections page will display the Search base and the User filter values. 
5. If users from a particular directory node is desired, you can make changes in the Search base field.
6. We’re currently talking about tweaking the values in the User filter field. Default value:
   (&(objectCategory=Person)(objectClass=User))Minimum change you should use per the MS article (below) to remove disabled accounts:
   (&(objectCategory=person)(objectClass=user)( !(userAccountControl:1.2.840.113556.1.4.803:=2)))

The default User filter will likely import more accounts than you are intending for use in SharePoint.  Remember, the accounts that are imported will also be crawled by the search indexer and will be available as search results from the People Search scope.  Because of this, we want to keep the accounts imported to a minimum so that the search results aren’t cluttered up with non-useful information. 

There are a number of good references out there for help with creating a specific LDAP filter for your import, including one by MS:  http://support.microsoft.com/kb/827754  

The good stuff:
There are a lot of queries and filters available, depending on what you’re looking to filter.  Regardless, what IS irritating is having to change your filter, Start full import and then View user profiles over and over until you get the list of accounts that you like.  So, what I’ve really been building up to is to use the following as a way to shortcut that process and test your LDAP filter before using it for your SSP import.    

1. Go to Run -> mmc  (This is the Microsoft Management Console)
2. Once the application starts, select File -> Add/Remove Snap-in…
3. Select Add
4. Select Active Directory Users and Computers.  Select Add, then Close
5. Select OK
6. Active Directory Users and Computers should now be on the Console
7. Expand Active Directory Users and Computers and the current domain should be visible
8. Select the current domain, and the accounts, etc should be visible in the right pane
9. Right click on the current domain in the left pane, and select Find
10. In the Find dropdown, select Custom Search
11. Select the Advanced tab

You should now be able to enter an LDAP query string and test it to see if you are getting the approximate number of users that you’d expect in your SSP Profile Import.  For starters, you could cut and paste the default value of the User Filter and see what users are returned by pressing the Find Now button.  A list of accounts and a count should be returned by the tool. 

Now, a few more notes for after you’ve found the filter value you want.  Once you’ve entered your new filter value and re-run the full import, you may notice that the Number of user profiles number reported on the User Profiles and Properties page hasn’t changed.  The page you want to check View User Profiles.  This page will show you both the total number of user profiles, as well as the list of active user profiles, which is likely a lower number and hopefully matches the number that the mmc tool reported during your testing of the query. 

Now what you need to do, and why you should tweak your import query before your first import, is remove all the accounts you don’t want.  On the View User Profile page, change the View dropdown from Active Profiles to Profiles missing from import.  You need to select each account, or each screen-full of accounts and delete them.  (I hope you don’t have a lot, because that will be a pain.) 

Once you’ve got all the junk cleaned out, start a full crawl on your profile database and your index should also be updated. 

Thanks to Brian for showing me this a few months ago… I’ve used it a bunch of times and have since passed it on to a number of co-workers and clients alike.  Hopefully you’ll find it handy as well.

Raymond and I are working on next week’s MNSPUG session - SharePoint and Social Networking.  It looks like we’re going to have a full house for this month’s MNSPUG meeting.  As of early last week we had 175 folks registered, which generally means we’ll get around 140-150.  So make sure you get there early for a good seat.  There will also be a Lunch and Learn session following the MNSPUG session with NewsGator presenting their SharePoint integrated products. 

Two other quick notes/reminders:

1. Microsoft isn’t hosting soda anymore.  :(  There are a number of businesses in the office complex for soda and other beverage options.  Microsoft continues to have coffee, tea and water available.   
2. There’s still a lot of road construction going on near the Microsoft office, but as of the last time we checked, you can still access the parking ramp for the 8300 building.  Allow yourself a few more minutes to navigate the mess.  

See you on Wednesday! 

(as requested, I’ll hold off on cutting my hair until after this week’s session )

Another quick reminder post about a topic easily forgotten:  Closing web parts as opposed to deleting them.  Deleting does just that and removes them from the page.  Closing may seem like the web part is removed, but its still loaded as part of the page.  Users unaccustomed to this may inadvertently add web parts to a page that they don’t think are there, but are still being loaded - and possibly contributing to poor performance of the page. 

Even when not in edit mode, web parts can be closed, though not deleted as shown here:

Once the page is in edit mode, a few more options are available, including delete.

There are a few ways to check the current list of closed web parts.  If you’re working with a publishing page, you can use the page menu and open the browse web part interface. 

The web part interface then shows a Closed web part in the gallery listing.

More than a few times I’ve helped someone troubleshoot poor performance on a page or site and open this page to find a bunch of closed web parts.  Once they were cleaned up and deleted, the page then performed much better. 

Another method to identify your closed web parts was highlighted by Joel not too long ago with a post about the SharePoint Web Part Maintenance Page, which will also list closed web parts.    

There are a number of ways to manage the web parts on your pages, just remember to be aware of closed web parts as one of those items to check when needed.   

I just read a blog post by Chandima Kulathilake (MVP) this evening that I wanted to throw a few thoughts out about.  The post (read the whole thing, its worth it) was initially about the pending availability of SP2 for the 2007 platform - but what really caught my eye was a description of an update method that I hadn’t considered before.  

In many cases, when patching SharePoint environments we tend to simply schedule downtime and run the patches on the whole system in one fell swoop.  As many of us are aware and Chandima reminds us, this can sometimes take a number of hours to complete depending on the size of the system. 

The particular scenario that Chandima identifies is one where you may have one or more sites that have high-availability requirements where downtime must be kept to a minimum.  In this case, you can by following his steps, upgrade one content database at a time.  This allows you to bring the site or sites in that content database BACK ONLINE and then proceed with upgrading each of the other content databases  while the one that has completed is available.  Bear in mind, the performance of the sites that are up are likely to take a hit due to both the full crawl that will start and the upgrading of the rest of the content databases as they are reattached to the farm.  But even if the performance isn’t up to its normal level, the sites are available. 

With this upgrade approach in mind, you may also want to think about your content database strategy (yes, I ramble about this topic regularly).  The upgrade and high-availability advantages puts yet another slant on how you plan content databases, sites and webs.  For example, if you have a site that you know is going to be high-availability, based on the information above, you may want to isolate it in its own content database even thought the site may not otherwise justify that strategy.  Remember, you also have tools available that can help move sites or webs around between content databases, allowing you to isolate sites during or after their creation if necessary.   

I’m really not saying much more than what Chandima mentions in his post, but I was pretty jazzed about it and wanted to elaborate even more on that point.  :)  Well done Chandima.

Along related lines, another good reference link to keep handy is a page kept up by Penny Coventry (MVP).  I’ve found myself pointing folks to this regularly when they ask how to tell what version they are on and what the latest versions are.

Have fun!

It used to drive me nuts when people came up with goofy names for their portals - usually because they could come up with some real doozies, spawn of the .com boom and generally more clever than they needed to be.  But at the end of the day, you need to name your sites. 

We had a guest speaker at the MNSPUG a few months back that was describing his company’s uses of SharePoint.  During that presentation, he made a statement that stuck with me about naming his site - actually about naming the sites and solutions that were built on the SharePoint platform.  I can’t quote him exactly, but he essentially stressed the importance of coming up with names rather than calling things ‘SharePoint’.  There are a couple of advantages to this. 

1. If you have more than one instance or solution, calling everything ‘SharePoint’ can be confusing.  Naming each solution reduces confusion.  When talking about ‘SharePoint’, let it be about the platform itself. 
2. SharePoint is a product and a platform.  In the unfortunate instance where something isn’t working correctly and users are becoming disenchanted with a solution - its better that they are frustrated with a specific solution rather than the entire platform.  Let people say there’s something wrong with ‘UberSource’ instead of saying there’s something wrong with SharePoint.  SharePoint is so much bigger than a single implementation - don’t get your users down on it unnecessarily.

It seems like a simple and somewhat silly thing to call out, but the bottom line is to name your SharePoint instances / portals / solutions - whatever.  It’ll make your life easier. 

Carry on!

(Wow, this is my 100th post… )

I ran across what I considered an obscure issue the other day and wasn’t able to find much for solutions - so here are a few details in the hopes that they might be helpful to someone else down the road. 

The short answer:  Are you having weird issues with a SharePoint page?  Are you using Content Editor Web Parts?  Check them to see if you’ve accidentally introduced incomplete or error-prone HTML.   

The longer answer:
I have a client that was attempting to edit a SharePoint site that had the publishing features enabled.  The user had full control and had checked out the page.  They had a number of lists on the site and a bunch of web parts in several zones on the page.  Two different issues were found. 

Issue #1:
When editing the page, even if only for a few seconds (like to move a web part) - then saving or publishing -  the page would time out with the following error:

“An unexpected error has occurred”

When returning to the site it says the following:

“Your current editing session has expired.  Before editing or saving any content you must refresh this page.”

When refreshing the page all changes are lost.  

Issue #2:
Also when in edit mode, when clicking on the ‘edit’ dropdown on one of the web parts, nothing would happen.  The edit dropdown would work just fine on the other web parts.  (this should have been my first clue to the answer)   

Notes:
Both issues are isolated to this page and this site only. 
No issues were seen in the Events logs or the SharePoint logs.   

Answer:
There were also a few Content Editor Web Parts on the page.  They both appeared to be working just fine.  When looking at the source for each of them, they included tags that were not necessary.  Tags that likely came from cutting and pasting from other applications.  Once these tags were removed, the normal functionality was restored.  The HTML from one or both of the Content Editor Web Parts was interfering with the HTML and code on other parts of the page.  What is normally considered a simple web part caused a not-so-simple issue from the user’s perspective. 

This is the post that finally tipped me off.

Carry on!

When creating wildcard inclusion managed paths, I’ve typically used single-level options - like those that are available with the out of the box configuration.  ‘/sites/’ and ‘/personal/’ for example.  While handy, this method can still be somewhat limiting when trying to organize sites that have more than one way of being categorized.  For example, you may want to organize sites by the type of site (projects, proposals, etc) or by an organizational division (State Dept, Dept of Agriculture, Homeland Security).  What I hadn’t previously considered, but does work just fine is multi-level options like ‘/departmentname/projects/’. 

Now, I’m sure some of you are already doing this, but I hadn’t considered it until playing around with things the other day and tossing some organizational ideas around.

There are of course some caveats to this approach.  If you have a lot of departments and a lot of site types, you’re likely not going to use this as you’d end up with a ton of managed paths that need to be… managed.  Multiply the number of site types with the number of departments and you’ll get the number of managed paths you’d need to create.  This also might not be an approach to use if you’re concerned about regularly occurring re-orgs that would impact the managed paths named after departments. 

But there are some scenarios where this would work just fine.  Namely with a limited number of first-level and second-level groupings. 

It would be REALLY nice if there was a way to attach metadata to sites (and lists for that matter) with out of the box functionality, but alas, we don’t have that this time around.  We’ll have to stick with adding information to sites via code customizations when needed by using the property bag. 

Now remember, managed paths are only used for the URL management of site paths.  They have nothing to do with what types of sites (templates or definitions) can be used within a managed path or how the content databases are organized (a topic in its own).  They could, however, be useful when customizations use URL strings to sort and filter lists of sites.  (Hmm… I’ll have to see what we can do in CQWPs or SharePoint Designer along those lines..)   

Another reminder:  Managed paths are created for a single web application.  Make sure you have the Depending on your taxonomy and needs, you may need to replicate them across web applications.

Carry on!

The second topic I presented on at the Best Practices SharePoint Conference was MUCH larger than could be accomplished in the time allotted - even when demo environments work perfectly.  :)  As Mr. Murphy would have it, my demo environment unfortunately did not.  So we went ahead with a session on “Aligning Business Needs and Processes” and discussed a number of scenarios that can be reviewed in the slide deck:  Download PowerPoint

As I mentioned during the session, I’ll be following up this post with more details on the topics discussed to make up for the lack of demos.  Please check back in the next week or so. 

Thank you to all to attended and stuck around.  I hope the information was useful.