Skip to main content

Larry Kuhn

Larry Kuhn
  

 Midwest Bloggers

  Arbindo Chattopadhyay
  U.S. Midwest SharePoint Community
  Ram Gopinathan
  Larry Clarkin
  Kevin Hammond
  Dave Bost
  Angela Binkowski
  Andrew Ehrensing
  John West

 User Groups

  Chicago SharePoint User Group
  Chicago .NET Users Group
  Chicago Windows User Group
  Chicago Visual Studio Team System User Group
Larry Kuhn > Categories
SharePoint Server 2010 Beta available out on MSDN
In all the hubbub surrounding PDC this week, I somehow didn't notice until a day later, but SharePoint Server 2010 Beta was posted up on MSDN for subscribers to download on 11/16/09.
 
Go here:
 
Sign-in with your MSDN account, and then navigate to Servers node in the left navigation, expand it and scroll down to find "SharePoint Server 2010"
 
11/18/09 3:43 PM CST Update: The public beta is now open, non-MSDN subscribers can download from here:
 
If you are going to install it, read this execellent blog post by Jie Li first:
SharePoint Performance and Load Testing resources
This is a great post that nicely summarizes and links to a wealth of useful information on this topic:
 
 
New series of posts about Preupgrade checker has started
Keep an eye on Jie Li's GeekWorld for details about the pre-upgrade checker that I previously mentioned in this post: WSS 4.0 Details Emerge via KB articles
 
The first installment is here:
 
Net-net: The future belongs to x64 - if you've still got 32-bit processors on your development workstations or servers it's time to go shopping!  Think of it as Microsoft's contribution to economic stimulus.
See, you were right - you weren't going insane...
Those mysterious glitches were not figments of your imagination or due to a solar flare randomly flipping bits in your SharePoint database... they were bugs.
 
Check the lists of which ones were fixed, and then sleep well knowing that your sanity is intact.
 
 
I for one happen to recognize several of these as tormentors of mine.  Hopefully they were exterminated before they could lay eggs.
Where do shortcuts in “My Network Places” come from?

Today my customer presented me with this simple question.  They had a whole bunch of shortcuts in their “My Network Places” folder but they hadn’t created them.  The shortcuts were being created automatically somehow, but just what action was trigging this behavior was not obvious.

After a quick bit of investigation, I found the following article which is a bit dated, but which describes this automatic shortcut creation behavior: http://www.winsupersite.com/showcase/win2k_980918.asp

 

After a little more digging, I found references to the “NoRecentDocsNetHood” registry value in this KB article: Policy settings for the Start menu in Windows XP (http://support.microsoft.com/kb/292504) which states:

Policy:Do not add shares of recently used documents to Network Places

Description:Remote shared folders are not added to Network Places whenever

you open a document in the shared folder.

Registry Value:"NoRecentDocsNetHood"

 

Armed with the above clues and context, I conducted some experiments accessing files stored in remote shared folders. Note that all of the results I document here were observed on a Windows XP SP2 client machine with Office 2007 SP2 installed.  Here is what I observed: A shortcut gets created when you directly open any file via a UNC folder view.  The specific steps are as follows:

a.       Navigate to the UNC path of a site’s document library:

b.      Start, Run, enter the folder UNC path (e.g.: "\\<someserver>\<somefileshare>\<somefolder>\<somenestedfolder>")

c.       Double-click on a file to open it in the application associated with the file type.

d.      A shortcut pointing to the UNC path of the file share is created.  (In other words, the UNC path will be \\<someserver>\<somefileshare>

 

Incidentally, further experimentation showed that if you happen to manually delete the automatically created shortcut while the application is still open, you will find that it will be automatically recreated if you invoke “Save As…” and save a new file in the same location as the original.  The interaction with the “Save As…” dialog box will become more important later…

 

The customer’s situation was a bit different though – the users in this case were not directly navigating to the paths in Windows Explorer.  And the automatically created shortcuts did not point to UNC paths, but rather to URL paths pointing to document libraries throughout various SharePoint sites they had access too.  But there was no rhyme or reason as to which sites had short cuts and which did not.  And in some cases there were multiple shortcuts pointing to the different locations within the same SharePoint site.  So, back to more experiments…

 

Automatic addition of SharePoint document library shortcuts to “My Network Places”

Based on my observations, here are the activities that trigger SharePoint document library shortcuts to automatically be added to “My Network Places” are as follows:

1.          Invoke “Save As…” on an Office document type that was opened directly from a SharePoint document library. The specific steps are as follows:  (note: you do not need to actually save a file – the shortcut gets created at the point when the “Save As…” dialog opens.)

a.       Navigate to a SharePoint site’s document library: http://<somewebapp>/sites/<somestie>/Shared%20Documents

b.      Click on the name of a Word, Excel or PowerPoint document to open it.

c.       Click on the Office menu, choose “Save As…”

d.      A shortcut pointing to the HTTP: path of the document library is created.

2.          Invoke “Save As…” and save a non-Office document that was opened directly from a SharePoint document library.  The specific steps are as follows: (note: in this case, you must actually save a new file before the shortcut gets created.)

a.       Navigate to a SharePoint site’s document library: http://<somewebapp>/sites/<somestie>/Shared%20Documents

b.      Click on the name of a text file to open for edit in Notepad.

c.       Click on File, Save As…, and save a new file in the same location as the original.

d.      A shortcut pointing to the UNC path of the site root location of the site of the document library is created.  (In other words, the UNC path will be “\\<somewebapp>\sites” - which is a mostly useless shortcut because no user should have permission to store or see anything at this location.)

3.          When you directly open a non-Office file via a UNC folder view.  The specific steps are as follows:

a.       Navigate to the UNC path of a site’s document library:  Start > Run > enter the folder UNC path (e.g.: "\\<somewebapp>\sites\<somesite>\Shared Documents")

b.       Double-click on a text file to open it in Notepad.

c.      A shortcut pointing to the UNC path of the site root location of the site of the document library is created.  (In other words, the UNC path will be “\\<somewebapp>\sites” - this is a useless shortcut in most cases, btw, because most users would not have permission to store or see anything at this location.)

 

As you can see – things are different when Office client applications are involved.  I believe that the underlying reason is because they kick over to use WebDav for interactions with SharePoint so long ast the WebClient service is running on the client workstation.

 

Hopefully this information will be helpful for some folks out there.

SharePoint Index Server Local Crawling affected by MS09-014 - KB 963027
Many customers I know have taken advantage of the "Index Server Local Crawling" tip that was published a long while ago by Joel Oleson over here: http://blogs.msdn.com/joelo/archive/2007/02/06/use-a-dedicated-web-front-end-for-crawling.aspx
 
Recently, Microsoft released "MS09-014: Cumulative security update for Internet Explorer" which, among other things, closed a vulnerability in NTLM authentication. Details of the security update are listed here: http://support.microsoft.com/kb/963027
 
Basically, there was a potential “man in the middle” security issue with NTLM authentication that has been mitigated by implementing the following behavior:  If you’re browsing to your own machine, and the URL you’re browsing to doesn’t match the machine name, then NTLM authentication will fail.
 
After applying this security update to SharePoint servers, crawls that are configured to use the Local Crawling approach and that use the FQDN as the start address of the crawl will begin to encounter HTTP 401 errors during the local crawl.
 
The NTLM authentication change was also included in .NET Framework 3.5 SP1, and is described in http://msdn.microsoft.com/en-us/library/cc982052.aspx
The solution is straightforward, and is documented both in the .NET Framework 3.5 SP1 article I just mentioned and in http://support.microsoft.com/kb/896861. Note that Method 1 is the preferred option to fix it.
 
Thanks to many colleagues who helped pull together the details here. Hopefully info this will save some folks some headaches.
SPDisposeCheck has been released.

I just found out that SPDisposecheck was finally released on MSDN Code gallery for public use yesterday.  If you write custom code against the SharePoint APIs (custom web parts, timer jobs, event handlers, etc.) you need to use this tool.  It will help you avoid coding pitfalls that can cause resource  leaks which lead to system instabilty.

 

http://code.msdn.microsoft.com/SPDisposeCheck

WSS 4.0 Details Emerge via KB articles
As a nice little Christmas gift, there have been several new KB articles published over that last several days that discuss the Pre-Upgrade Checker that will ship as part of WSS 3.0 SP2.  The role of the Pre-Upgrade Checker is to enable you to assess your environment for any problems you might need to address before you upgrade to WSS 4.0 when it becomes available.
 
The "root" KB article is here:
 
That one has links to others that describe various rules that the checker will apply to generate warning and error messages.
 
The CustomListView rule article hints at some improvements in the tried and true list view: "the new XSLT-based list view" and the CustomFieldType rule article hints at "the new XSLT-based field types" - hmm.  Sounds interesting.  Sounds like I need to hone my XSLT skills.
The Long Running Operation Status list

While troubleshooting an issue for a customer of mine recently I got to learn about a dark corner of the MOSS 2007 Publishing infrastructure that doesn't seem too well documented.  The problem they were having was that users who were members of the "Designers" SharePoint group were encountering errors when using the Site Content and Structure page (_layouts/sitemanager.aspx, accessed via the Site Settings -> Manage Content and Structure menu) to move publishing pages from one subsite to another within the site collection.
The process would always start out promising, with a progress display on the LongRunningOperationProgress.aspx page, similar to this:
lro1

But it would end unsuccessfully, with a final message like this: lro2

The frustrating thing about the situation is that SharePoint was trying to help – there is that tantalizingly named button there "View Logs", but alas none of the users encountering the problem could actually view the logs – when they would press that button they would an Access denied message.
So, we actually had two problems – first of all, the pages could not be moved, and secondly the people trying to troubleshoot things couldn't see the log messages. The first problem turned out to be caused by insufficient permissions for the user performing the move operation at certain points within the site hierarchy.  This was easy to pinpoint once I could actually see the log messages.
The remainder of this post examines the second problem of getting at these log messages. In my case, I didn't even know where these log messages were actually stored.  After a little digging around I found that I should be looking at Site Settings -> Content and structure logs (_Layouts/SiteManager.aspx?lro=all).  So I got a Site Collection Administrator's assistance and began exploring.
When you get there, you'll see something like this:
lro3

It may not be very obvious from the above screen shot, but the view of the log messages is not very usable.  Imagine if there are several hundred log messages (as there were in my customer’s production environment) – there's no way to filter or sort or export these messages…  I figured that is this view was really backed by a plain old SharePoint list somewhere. I just needed to find it and then I should be able to do what I needed to drill down on details for the issue I was investigating.  After some searching on the internet, I found these posts about Long Running Operations (Part I and Part II) that provided what I needed.  Thanks txs8311, whoever you are! There is a hidden list called the "Long Running Operation Status" list that is created under the root site of site collections that have the Publishing feature enabled.  You can see this and other hidden lists if you open the root site in SharePoint Designer:
lro4

In my situation, I could not use SharePoint designer to get to the list on the customer's site, so instead I just typed the list's URL (http://<portalURL>/Long%20Running%20Operation%20Status/) into the browser, which showed me a view like this:
lro5

Now I finally had the tools I needed.  I created a new private view that showed all of the columns I was interested in, and that filtered just show items that had "Errors Encountered" begins with "<" (that field contains an XML string with details when things go wrong) and that sorted on Created date descending.
While I was at it I also took a look at the permissions on this list.  They are not inherited, and they only account that has access is the web application's application pool account.  I guess this would explain why the users were not able to view their own log messages, but site collection administrators could.  I think it would be safe and useful to grant Designers and Site Owners and Site Managers groups Read permissions on this list.  I tried it out in my test environment and it works nicely.  The "Content and structure logs" viewer even filters the list of log messages only show those of the user.  I don't know why it doesn’t setup that way from the start.

Hopefully this saves someone some head knocking.

Best Practices Resource Center for SharePoint Server 2007
There is a terrific new resource out there that I want to tell you about - the Best Practices Resource Center for SharePoint Server 2007
 
When I talk with customers they always ask lots of questions around wanting to know what approaches and tactics work best for other customers.  It is a very reasonable way of thinking - if they could just fast forward past all of the "learning from their mistakes" part of building out their environment, they'll be done sooner and their users will be happier.   I'm always happy to share what I know, but unfortunately the fact of the matter is that I can only provide so much insight, because I personally haven't encountered enough variations "in the wild" in order to truly judge what approach is "best" in some situations.
 
Since my experience is common to that of my colleagues in Microsoft - members of the product team, support and consulting organizations, we wind up taking the questions we get from our customers and farming those out among ourselves.  And we have seen some patterns emerge.  Now in the Best Practices Resource Center, we have pulled together a summarized set of best practices that we have found work well and address the most common questions that come up in each area of the vast SharePoint product landscape.
 
Look them over and try them out.  And give us feedback where you agree or disagree, based on your own experience.
1 - 10 Next

 Error

Web Part Error: A Web Part or Web Form Control on this Page cannot be displayed or imported. The type could not be found or it is not registered as safe.

Error Details:
[UnsafeControlException: A Web Part or Web Form Control on this Page cannot be displayed or imported. The type could not be found or it is not registered as safe.]
  at Microsoft.SharePoint.ApplicationRuntime.SafeControls.GetTypeFromGuid(Guid guid)
  at Microsoft.SharePoint.WebPartPages.SPWebPartManager.CreateWebPartsFromRowSetData(Boolean onlyInitializeClosedWebParts)