Site Owner Unable to Edit a Page in SharePoint Designer Due to an Inherited Master Page

Ok SharePointers.. I'm wring this blog post to recap a tricky work-around I came up with as result of a Microsoft "feature" in SharePoint 2010.  Here are the details, the problem and finally the solution I came up with.  perhaps this "out-of-the-box" kind of thinking may help you if you encounter the same situation.

The Set Up: Currently on my contract, we have several farms, one of which is an internal portal that is used for employee only collaboration.  It requires an Active Directory account and the layout of the environment consists of a main Site Collection for each bureau and sub sites created for each different department below that as they are requested.

The Problem: A site owner contacted me unable to edit a site page using SharePoint Designer.  he sent me the following screenshots (names have been blurred to protect the innocent):

What this error tells us is that the user does not have permissions to the custom master page that we are using on the site collection.  Since it is a sub site that inherits it's master page from the top level site collection, we are having a permissions issue.

The Details: As you will read in this Microsoft support article: http://support.microsoft.com/kb/2592376

Overall, a user needs to be a member of one of the following groups at the site collection level to be able to use SharePoint Designer and modify SharePoint content:•Site Collection Administrators•Designers•Owners

Since I cannot give this site owner site collection admin, owner or designer permissions to my top-level master page library, and I was unable to get the site to recognize the sub site's master page library in the master page settings, the user was getting the error above.  Simply creating a new site collection for the user and migrating the data was too much effort, so I had to be a bit tricky with how to make this work.  

The Solution: I created a new folder in the top-level master page library and broke inheritance to the folder, giving him designer permissions.  I took a copy of the master page and placed it in that folder, then set the site (and all sub-sites) to inherit this new master page.  He now had the necessary permissions to open site page and edit the content without the master page error, and I was able to maintain security by not allowing him elevated access to the real master page library.

I'm not sure if this is the best way, but this fix took all of 5 minutes to do and the user had all the functionality he needed and was back in business without any impact to the end-user look & feel (or needing to migrate content from one site to a new site collection).  If anyone has any other suggestions or perhaps a better way of being able to get the sub site to recognize it's own master page library (using the "_catalogs/masterpage/Forms/AllItems.aspx" string), please feel free to post a comment in the section below.

Enjoy!

Launch a Hyperlink from the Quick Launch Bar or Top Navigation Bar into a new Tab or Window

How many times have you wanted to open a link to a list, library or site from the Quick Launch bar into a new tab, but when you right mouse-click on the link, those options aren't available?  If you're a casual SharePoint user, this is the menu you will get:

My personal work-around to this frustrating function was to duplicate the tab in the browser and then click the link normally.  It didn't take too much time to do this, but it was inconvenient.  I just couldn't understand why Microsoft wouldn't allow me to open a SharePoint link from the navigation to a new tab/new window. But I recently discovered a way to make that menu appear.  It takes some precision clicking, but once you get the hang of it, it will save you time and effort.  Plus you'll have a nifty new trick to show your colleges in the office.  Imagine how cool you will be!

First, you have to find out where the edge of the clickable area ends.  On the Quick Launch bar, it is typically right at the edge of the cell.  On the top navigation, you should be able to see the separator between the navigation items as shown in the image below:

If you hover over the very edge of these, the right mouse-click menu will change to the one we are all familiar with, the one with the option to open in a new tab, open in a new window, save target as, etc:

Now that you have the trick, go perfect your technique.  Go ahead, give it a shot.

Manually Updating Passwords in SharePoint

I had the pleasure recently of being tasked with updating application pool and other service accounts in a mixed version, multiple SharePoint farm SharePoint environment.  Since this is routinely performed annually, I was disappointed to learn that there was very little documentation and truly no telling exactly where each of these accounts may have been used throughout the farms.  Since these environments were in production, it was very important that we took our time and tested functionality each step of the way.  Previously we had an issue where we issued a command to force a single password change through SharePoint, but it automatically changed every single farm password causing a mismatch between what SharePoint had as a password verses what it was actually set as in Active Directory.  This was a disaster!  We had to manually update the passwords in SharePoint using powershell.  Needless to say, we disabled all managed accounts from automatically changing the password.

So we started with the obvious, managed accounts.  Each account had to be simultaneously changed in Active Directory and then updated in SharePoint.  Once we completed the the managed accounts, we restarted the services to make sure they were working properly, and checked each server to make sure they replicated properly.  Below I've listed a few lessons learned and perhaps even some ideas for proactive approaches that you can take now to make the next password update process much more pleasant with a proven and predictable outcome. 

These are in no particular order:

1. Make sure the timer service is started on all servers in the farm.  This will insure that the passwords are replicated from the managed accounts section in Central Administration to the services/applications across the farm.
2. If possible, do your password changes off hours.  Although hearing user complaints about something not working right would be an excellent indication that a change was not applied properly, it's best practice to reduce the impact as much as possible on your user population.
3. Take one step at a time.  Change the password in Active Directory, then change it in SharePoint, then test completly.  Only once you are positive the change was successful should you move to the next.
4. If you do not already have a SharePoint list of all the service accounts you have in your farm and where they are used, this is the perfect time to start one. It will save a ton of research time before your next password change and allow for the process to be shared by multiple teams.  I use a custom list with columns such as: service account name; account type; app pool or application service, details, last password change, etc.  I also recommend using a program like KeyPass or PasswordSafe to keep track of current account passwords and pass phrases.
5. Sometimes you have to manually change the password on the application pool itself in IIS Manager. Also be sure to update secure store service IDs.  This is where your list will pay off big time because once you go through this process once, you will know exactly where those accounts are being used so you can update all instances.

Having written proceedure and clearly documented details not only saves you time and effort the next time you need to manually change passwords, but it's also artifacts that can be passed down to newer team members as staff or responsibility changes.

KB2844286 Security Update on SharePoint 2010 - Causing List View Web Parts to Break

I received a call this week from an end-user reporting that a web part on his site was throwing the following error.  

Here is the text version of the error he was getting:
Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Microsoft SharePoint Foundation-compatible HTML editor such as Microsoft SharePoint Designer. If the problem persists, contact your Web server administrator.

I logged into his site, but it initially rendered just fine for me so I figured it was on his end, but the next day, I too received the error.  So I looked into the ULS Logs on the WFEs to see if I could identify the problem.  As with most cases, the details were limited but there was one thing that stood out that I was able to search on:

Error while executing web part: System.NullReferenceException: Object reference not set to an instance of an object.

After a quick search, I was able to track this down to a Microsoft Security Update that was applied to our web front end servers over the course of the week.  We have two load-balanced Web Front End servers in our farm and it turns out that both did indeed receive the automatic update.  One server updated on the 13th of July (this was the server that the end-user was hitting) and the other server was updated on the 17th of July (which is the one that I was hitting and the reason why, a day later, I was getting the error).

At this point, I needed to check the OS to find the exact KB update that was associated with the issue.

Windows XP and Windows Server 2003:  KB2844285
Windows 7 Service Pack 1 and Windows Server 2008 R2 Service Pack: KB2844286 
Windows Vista Service Pack 2 and Windows Server 2008 Service Pack 2:  KB2844287

Here is the Microsoft Security Bulletin for July 2013:
Microsoft Security Bulletin MS13-052

As a temporary workaround, we found uninstalling the update (KB2844286) from the servers (all WFE’s and App servers), rebooting, and then performing an IISReset on the servers will resolve the issue. Several others have experienced this issue as I found here: http://social.technet.microsoft.com/Forums/sharepoint/en-US/cc9a557b-93cd-40d5-965c-e0a2f107624d/unable-to-display-this-web-part-error-message-after-patch-kb2844286 and here: http://social.msdn.microsoft.com/Forums/en-US/871a0661-05d0-4f3a-b66d-2504552142bd/error-while-executing-web-part-systemnullreferenceexception-object-reference-not-set-to-an

At this point, this is the best information I was able to find.

Also according to other blog/forum posts I've read, it appears this error "typically" appears when a list or web part view has had the XSLT customized.

Post SharePoint Saturday Recap (SPSDC)

So this past weekend was SharePoint Saturday DC at the Microsoft facility in Chevy Chase Maryland (close enough to DC).  My company (Xgility.com) was a sponsor so we had a booth with Pint Glasses as a give-away.  I was also tasked by my boss to take some photos from the event.  Although I didnt attend as many sessions as I would have liked (between manning the booth and walking around with the camera), it was a fun time and I encourage anyone who is interested in SharePoint to attend as many of these free events as possible.  It's a great opportunity to meet people you follow on twitter, or just talk about how your companies can help provide services to others.  I find its a great way to spend some time with team members that you dont normally get to work with.  I always walk out of these events with more knowledge than I had walking in, whether that's learning new technology or just simply learning about a product/business that I didnt know existed.  It's all about the networking, baby!
So here are the top 10 things I got from Saturday's event (in no particular order):

1. Pistachios are NOT just tasty snacks
2. Parking is much easier when someone else is driving
3. If you bring a pint, they will fill it - SharePint can happen anywhere, at any time
4. Always prepare questions in advance for the "Ask a Microsoft Expert" Q&A session - use it as an opportunity to stump them and watch them squirm, dodge, and ask to follow up with you after the event
5. Always grab extra SharePint tickets because they will come in handy later
6. Even the most annoying/uninteresting SharePoint conversations are better with beer
7. You can customize SharePoint Search in 2013 to really screw with people.  For example, when someone searches on a commonly used term, have it return the results of something oddly fascinating but not at all relevant - then let the fun ensue
8. If you get 10 people from your company to show up to a free event on a Saturday, you're gonna have a blast, especially if at least one of them is from out of town
9. Always pack breath mints and a spray can of deodorant, just in case someone in your group is a little funky
10. Visit vendor booths early to get the best swag

Thanks again for everyone who came, saw and conquered the lastest installation of SharePoint Saturday DC.  The next event in this area is scheduled for Saturday December 7, 2013 in Reston Town Center.  You can sign up for updates/register here: http://spsevents.org/city/wash-dc/Pages/SPSDC2013.aspx

Handcuffed by Technology

Most of us have been there at some point in our career.  You re in a requirements gathering meeting with a client to discuss the project, get an understanding of the business processes and discover the items that will be the foundation of your development efforts.  Everything starts out fine.  You re looking at their current systems, discussing what works, what doesn't work, what needs to be changed, what needs to be different... all good information to help you build the plan of action.  When all of a sudden the focus changes.  The client starts whipping out Visio drawings of how they envision the sites to be created or they want folders in this library, etc.  Then they call in the incumbents, who are clueless on SharePoint and want to argue about how its an inferior product to the custom solution they have been overcharging the customer with for years.  It can all quickly go to shit right in front of your eyes.

Afterwards, as you re going over the notes, you try to think back to where everything went so wrong.

I can tell you from first hand experience, it was the moment you started to let technology run the meeting.  The second you started talking in 0s and 1s you lost the battle.  But the war can still be won.

It's important when you are gathering requirements for any project that you focus on the business needs.  The WHY, the WHAT.. not the HOW.  The how is what you are getting paid the big consulting bucks (or meager corporate salary) to provide.  That is where your expertise with the product, your years of experience and understanding of the requirements comes in to play.  But you can be in trouble if you do not first understand WHY they want a new system.  What aspects of their business need help?  Are we making an improvement on their current business processes and if so, understand and document them.

Too many times I'll have a client ask me to create a workflow to do X, Y and Z.  or they will come to me and as for a list without thinking about the metadata or how will that list be interacted with - do they want dashboards or certain views.  They will say they need a top-level site with a list that filters to a sub site so blah, blah, blah.. you get my drift.  At this point, I always take a step back and ask WHY?  Don't think in terms of technology because technology is a solution to a problem.  You want to know what the problem is so you can apply the correct solution.  Take a moment to ask them to walk you through the human process of that particular aspect of their business, so you can understand WHAT needs to be addressed and WHY it is not working now, before you start throwing "technology" at the problem.  Sometimes technology is the problem.

So next time you're watching that meeting fly off the tracks like a runaway train, remember to focus on the human processes - its always a safe bet to take a step back, forget about the technology for a moment and focus on their business needs.  You'll be a better solutions provider for it.

Don't Stop... Believin'... or Learning

I realized something today.  You never stop learning in this business.  Hell, I think I've forgotten more than I've learned, but either way, each day is a new day to learn something new.  And I'm here to tell you that an old dog CAN learn new tricks.

I looked back on a previous project I worked on.  It had only been about 6 months or so, but I was using some techniques and technology that I was fairly new to me at the time.  Not that the project wasnt good; the client was very satisfied, but to my (now developed) eye, I can see some things that I would now do differently.  You see, since that time, I've done similar projects and I've learned a lot.  I have developed "standards" that I hadnt had before.  I organize my thoughts and planning in a different way.  My entire approach is different and because of this I can see a dramatic difference in the quality of my work.

I guess this holds true to just about everything in life.  The more repetitions, the more automatic it becomes.  The more experience - the more lessons learned, the better the results.

I cant go back and re-do those projects, but I can (and will) take each new challenge as an opportunity to grow and learn.