Old Friends – New Possibilities

In a post entitled “Time for a Change” a few weeks ago I announced my decision to leave Mindsharp and return to the world of fulltime consulting.  At the time I hadn’t decided whether that meant a fulltime position with a consulting firm or restarting my own company called Don’t Pa..Panic Software.  I’ve spent the last month talking to a number of companies and I’m happy to announce that I have accepted a position as a Senior SharePoint Architect/Lead Consultant with ShareSquared.

ShareSquared I’m really excited to be joining the ShareSquared staff.  It means that I’ll continue to work with some of the best and brightest talent in the SharePoint community, just like I did at Mindsharp.  I’ll be working with people like fellow SharePoint MVPs Maurice Prather and Gary Lapointe and other SharePoint notables like Keith Richie. I’m honored to be invited to join such a talent pool. So, if you are you looking for a team of SharePoint experts, then ShareSquared can help … drop us a note.

Editing a SharePoint Master Page in Visual Studio 2010

I’ll be the first to agree that the best tool for editing a SharePoint master page is SharePoint Designer (SPD).  SPD is able to display both a code and “WYSIWYG” view of the master even if objects on the page are referenced using virtual directories, relative addresses, or addresses that contain dynamic placeholders.  Because Visual Studio can’t open a SharePoint site in place it is unable to provide the same level of editing support. But the problem is that a master page edited in SPD is “customized” and can only be used for that one site (or a single site collection if publishing features have been enabled.) So it has become a best practice to create a custom master in a separate SPD development environment, export it to the file system, and then deploy it in production as an “uncustomized” master page using a feature in a solution. (I documented how to deploy an SPD 2007 master page as a feature in a previous blog here.)

Editing master pages in SPD 2010 continues to be the best practice, but it can be cumbersome for small changes to Enterprise master pages already deployed via a Feature. Sometimes its just not practical to upload the master to a Development site master page gallery, edit it in SPD 2010, and then download the edited copy to be packaged in Visual Studio 2010 and re-deployed to an Enterprise. In those cases it would be nice to make a quick edit in VS 2010. But VS 2010 is unable to interpret the master page in the context of a live site and defaults to the standard code view editor when opening a master page.  This leads to two specific limitations that make even simple edits more difficult.  As you can see from the screen shots below there is no support for expansion/contraction of code sections and Intellisense support is greyed out.



This makes it even more difficult to edit master pages in a code only view. To avoid these limitations you will need to tell VS 2010 which editor to use when opening the master page.  To do this Right-Click on the Master page to be edited in the Solution Explorer and select Open With… from the context menu.  A dialog will open showing all the different Editors that are available.  Highlight the Master Page Editor (Default) entry and click OK to open the Master page using the Master Page Editor in place of the Source Code (Text) Editor.  (Note: Although the Master Page Editor is set as the default just clicking on the master page in Solution Explorer will actually use the Source Code (Text) Editor.  The screenshot below shows the master page after it has been manually loaded into the Master Page Editor using the Open With… menu.  Notice the presence of both Expansion/Contraction Outlining and Intellisense.


A similar problem exists when opening .aspx pages that are not stored in the _Layouts virtual directory.  You can enable full code editing of these pages by using OpenWith… and choosing Web Form Editor (default).

Time for a Change

If there is one thing in life that is a constant it is that things are always changing.  New products are released, new technologies developed, and new job opportunities arise.  I decided a few weeks ago that it was time to make a change like that in my life.  I decided it was time to bid my position as a Principal Trainer/Associate at Mindsharp goodbye and return to the world of fulltime consulting.  So two weeks ago I submitted my notice and yesterday was my last official day as a Mindsharp employee. 

I’m taking the rest of the year off to spend some time with family and friends and get some serious writing done on a book I’m co-authoring with Daniel Galant about SharePoint Designer 2010.  Then starting in January I’ll be back to deciding where I go from here.  I’ve started talking to several companies about a position as a Senior SharePoint Architect/Developer.  Or I may decide to go back to being an independent consultant for my own company, Don’t Pa..Panic Software.  Whatever I decide I wish all my friends at Mindsharp well.  Keep your eye on this blog.  When I make a decision on where I’m going I’ll post it here.

Restricting Anonymous Access to Specific Pages in a SharePoint Site

A question came up several months ago in one of the Developer Panel presentations at the Best Practices Conference about whether access to individual pages could be restricted on a SharePoint anonymous access site. One my friends who was on the panel replied that he didn’t think it was possible. Since I had previously researched that question for a client I pointed out that it was indeed possible, but that it was not an intuitive process. My friend then jokingly asked whether I had Blogged on how to do it and when I responded "No" he pointed out that I shouldn’t be discussing things in public that I hadn’t Blogged on. It was a joke, but he was right. I left the conference fully intending to blog about the process the next week, but never got around to it.  Its now the end of the year and things are slowing down a bit so I plan to fix that issue by blogging on several topics that have fallen by the wayside in the last year. This is just the first.

In a normal anonymous access ASP.NET web site access to specific pages can be restricted by modifying the NTFS security permissions on the specific file to exclude the IUSR_computername user from having read access to the file. But this model raises two issues when trying to do the same thing in a SharePoint anonymous access environment. First, SharePoint doesn’t make use of the IUSR_computername account specified in IIS for anonymous access, so changing the SharePoint permissions associated with this account will have no effect. Second, although security permissions can be configured at the Web site, List/Library, or item level in SharePoint anonymous access can only be configured at the first two of those levels. Adding the IUSR_computername account as a SharePoint user and restricting item level permissions for that user has no effect on the permissions granted to an anonymous user.  So on the surface there appears to be no way to configure anonymous access rights on a specific page or file to require that viewers of that page be authenticated.

But if you dig a little deeper into how anonymous access really works in SharePoint you discover that there is a way to require anonymous access for specific pages and files. First, you need to understand that anonymous access users in SharePoint are actually provided the same permissions that a user with the Limited Access permission level is given.  When you configure anonymous access at the Web site, List or Library level in SharePoint you are telling SharePoint to allow all non-authenticated users access to objects at that level as though they had the Limited Access permission level.  By default this permission level will be inherited by all objects below it in the hierarchy.  It is this Limited Access permission level that gives anonymous users access to list items and documents.  But that only works if security inheritance isn’t broken.  If you edit the specific permissions on a list item or document, that item will only have the permissions you assign to it.  Since you can’t manually assign limited access and anonymous access is not configurable at item or document level this security setting will prevent anonymous users from accessing the list item or document.  When an anonymous user tries to access a document or list item that has specific security settings they will be prompted to log in.

Slides from SharePoint Saturday Kansas City: Customizing the Ribbon UI

SharePoint Saturday Kansas CityIt’s been a week since I was in Kansas City doing a presentation on how to customize the new SharePoint 2010 ribbon.  It was a busy week, so I’m just now getting a chance to make the slides and Visual Studio project that I used for the talk available for download.  I’m hoping to transfer the talk into a series of Blog posts over the next few weeks, so if you missed the original talk stay tuned.  Here are links to the downloads:

Customizing the Ribbon presentation slides

Visual Studio 2010 demonstration Project