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.

Whoops! So much for regularity....

I cant believe it's been 3 months since my last post.  Yeah, I'm a blog-slacker.  Truth be told, I've still trying to figure out what kind of stuff to talk about. I guess I can mention some of the projects I've been working on lately.  Maybe people will find these interesting....Let's see, I've built a Resume Repository System, where Job Seekers can publish their resume through an InfoPath form and the data is then displayed in dashboards for Hiring Managers, HR, etc based on qualifications, experience, previous employers, etc.  Then there was an Opportunity Pipeline System that tracks the lifecycle of contracts and task orders.  Another one was an Inspection and Evaluation System that tracks the inspection of aircrafts throughout a region, ties it to a particular vendor including contracts and also organizes pilot evaluations.  This one is pretty cool because I built dashboards so they could filter a particular pilot base don region or vendor and likewise filter inspection data based on organization, region or contract.  Another one I built recently was a Collaboration System that centrally managed all support requests for a government client.  I really thought out of the box with this one and implemented an Self-Servive Support InfoPath form that not only allowed a person to submit a support request, but in the form itself, you could select your topic and if there was Knowledge Base article available, it would display it.  Talk about using the old noggin...
If anyone is interested, maybe I can get more in depth with some of the features.  or not...
Until next time...
-E

I started this SharePoint blog today because there just arent enough personal opinions about technology floating around the Internet.  I believe I have a style of writing that people would enjoy reading (if you like your eyes poked with a stick, that is) and a couple minutes on my hands to pass along some potentially interesting information.  If you appreciate sarcasm with a side of geek humor, you will feel right at home here. Seriously though, this is my contribution to the SharePoint community and I hope you enjoy it.