The LandPhil be honest, be honorable, be kind, be compassionate, and work hard.

January 18, 2011

SharePoint: You’re not the only one that can’t find anything

Filed under: SharePoint — phil @ 9:30 am

I find it amusing that as I delve deeper and deeper into SharePoint, I find that a lot of my questions have been answered.  Unfortunately, it’s not always easy to find them.  Or, they’re actually being documented in near real time to my looking for them.  Or, they’re being discussed at a higher level at conferences and summits occurring, for all intents and purposes, right now.

Microsoft’s TechNet has a LOT of good information, but it’s very vanilla, and in order to answer specific questions you need to sort of piece together the answers out of the information provided.

Specific to actually building a farm, from the administrator’s standpoint, Joan Resnick Ehrlich has a fantastic set of articles that she’s publishing over at  The first one is titled: Life on the Farm: SP2010 Configuration – Prep Work Part 1.

January 11, 2011

SharePoint: Disaster Recovery How-To (SharePoint 2010)

Filed under: SharePoint — phil @ 12:39 pm

No one has a good “How To” out there for Disaster Recovery for SharePoint. Hopefully, this will provide at least a little bit of insight into that process. I will try to document as much as I can the implementation that we’ve decided to use and the steps I’ve gone through to bring it to fruition.

There are many ways that you can set up “disaster recovery” for SharePoint. More than a few of them do it at the SQL Server level. Unfortunately, in order to do that, you need a very fast link between your live SQL servers and your DR SQL servers. We don’t have that link. So, instead, we’re using what’s referred to as the Hot-Standby DR plan. In it, you asynchronously mirror all databases that are supported to be mirrored. This DOES NOT include the SharePoint_Config database, among others. With that in mind, here’s what we did:

First, we set up our production (and development) environments. Once those were done, I installed SharePoint 2010 on the first DR server. I then configured Central Administration for the DR environment using the same steps that we’d used for development and production. Then, I had our SQL DBA configure asynchronous database mirroring between our production SQL and DR SQL servers (for the SQL Admins, that would be high availability, not high safety. The principal database doesn’t wait for changes to commit to the mirror database, for production speed purposes. We also did not configure a witness. Our production and DR sites are in two different data centers, but we do not have a third data center at which a witness could be located. We also didn’t want the overhead or problems associated with the witness being inaccessible at any point.) This is where I believe I made my first error.

I then attempted to rebuild the service applications while pointing the database links to the mirrored databases. For the Business Data Connectivity service application, it worked, but with errors. Those errors were such that I was unable to get into the configuration of the service application itself. So, I removed that service application. I was able to recreate the Managed Metadata Service application in this way, but only by doing it as the exact same user as when it was originally created (that user becomes the term store administrator, by default.) I ran into the same problems with the Secure Store as I did with the BDC.  (Edit:  As it turns out, the Managed Metadata service application didn’t work either.  It worked for me because I had inadvertently mistyped the database name and had created a brand new, non-synced Managed Metadata service.)

It then occurred to me that perhaps doing a granular backup of the service applications in the production environment and then restoring them to the DR environment would work. After a few failed attempts at actually capturing the backups (don’t write directly to a local drive, for whatever reason, some of the files created don’t allow you to write to them. Instead, share a directory and then point to the shared directory instead), I was able to get one. However, when I tried to restore it, I kept running into errors that the databases were already being restored. I believed that to be because of the mirrored nature of the databases.  As luck would have it, I was right.

Ultimately, how I accomplished the DR site was to delete all of the mirrored databases.  Run backup from inside the production central administration of the individual service applications and their proxies and restore those service applications and their proxies to the DR site.  I also backed up the one web application that we had configured and did the same thing.  I thought that perhaps I could do the solutions as well, but I received errors.  You can’t restore a solution to “deployed” status.  Rather, the solutions get copied over and you will need to redeploy them to the target web applications.

The DR site is up.  Things left to do:

  • Document procedures for failing over to the DR site
  • Document procedures for failing BACK over to the production site
  • Test DR site fail procedure

Fun fun fun.

SharePoint: PowerPivot Installation How-To

Filed under: PowerPivot,SharePoint — phil @ 12:33 pm

The first question you have to ask yourself as a new SharePoint administrator in this situation is “What the hell is PowerPivot?” Is it a database? Is it an SQL Server instance? Is it a web application? Is it a service application? The answer to all of those questions is, unfortunately, yes. This makes it sort of complicated.

This all started because we need PowerPivot to chug data for one of the projects I’m involved in. So, of course, it needs to be installed on our farm. Easier said than done.

There was a lot of questions revolving around being able to install PowerPivot on a separate application server in the application layer of the SharePoint architecture. After some poking around, I found some documentation on the subject confirming that it is indeed possible: PowerPivot – Existing Farm Installation (Document)
That’s a handy document to have.

The next step was actually confirming that we could do the installation in an existing farm format. This is where it became truly trying of my patience. The first step is to obtain the SQL Server 2008 R2 media. On the machine you’re going to install PowerPivot, insert the media and launch the SQL installation script. The installation process itself takes forever as the script will run multiple passes of multiple checks to make sure everything is in place to proceed. It is, however, not fool-proof. This means you typically have to wait between 10 and 20 minutes to find out it failed. I’ve been through all of that many times now, so I’ll spare you the headache.

Here are the things that you need to do before running the installation:

  1. Make sure the account you are doing the installation with is the original farm administrator account. It will not work with just any account in the farm administrator’s group. (One of the SQL check phases will fail.)
  2. If you have already installed SharePoint 2010 (which is most likely the case), you will have also already run the pre-requisites installer. This will screw up the SharePoint/PowerPivot integration assembly. Follow the workaround detailed here:
    You will be using Method 2. (I had to use Method 1.)
  3. Run the SQL installer.  You will be adding new features.  Choose PowerPivot for SharePoint.  At this point you have to choose between installing in a New Configuration or an Existing Farm.  In order for New Configuration to work, you need to have done the initial SharePoint 2010 installation, but not run the configuration wizard.  If you have a SharePoint_config database already, you are an Existing Farm.
  4. Wait.
  5. Once it completes (preferably with no errors), you will need to create a PowerPivot service application before configuring PowerPivot on your farm.

December 29, 2010

SharePoint: Disaster Recovery Managed Accounts

Filed under: SharePoint — phil @ 7:20 am

So I’m setting up our DR farm here and I had an epiphany while I was doing the configuration. I’d mimicked all of the settings of the production farm including using managed accounts… the same managed accounts. I was about halfway through when I realized that would probably be a bad idea. Since the two farms would want to change the passwords 1) at the same time (remember I said I was mimicking the settings) and 2) to different things.

So I backed out and got a different set of service accounts to use as managed accounts. In trying to remove the old service accounts from the managed accounts console, I kept running into errors. Turns out you have to disable the auto password changing first, then remove the account. Pretty obvious, actually, but thought I’d share. Point. Heh.

Edit:  We actually ended up not using the password changing policies of the managed accounts.  Preferring to instead keep the accounts all on the same password change schedule.

December 21, 2010

SharePoint: Installation fails

Filed under: SharePoint — phil @ 7:48 am

Recently, we had a lot of problems with the SharePoint 2010 install executable failing.  The exact error that we would get was “A system restart from a previous installation or update is pending.  Restart your computer and run setup to continue.”  We’d rebuild our virtual servers and test the installer and it would work, but then the next day it would fail.  Or sometimes it would fail that first time.  We were very confused.

The answer was hinted at here: SharePoint 2010 Installation.   There was a registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations
that had information in it.  The solution above suggested that you change the key name from PendingFileRenameOperations to PendingFileRenameOperations2.  That’s sloppy, in my not so humble opinion.

Now, the other folks had tried this solution in the past, with limited or no results.  The trick here was to figure out WHY that key had data in it.  Previously, they would do what the article suggested and the key would just be remade and refilled with information, stalling the installer again.  Being a sysadmin, I wanted to know what and why that key existed to begin with.  It was a short trip as it turns out.

The enterprise here installs a client on every machine to do data collection for inventory and software metrics.  The client is the Scalable Software, Inc Survey client.  That client locks a specific file and for whatever reason, throws it into that key.  Once we’d put that together, it was a simple matter of stopping the SSI Survey Client service, setting the service start to manual, and then rebooting the server.  After multiple servers, we confirmed that this was indeed the cause, and the solution.

So, the moral of the story is:  Don’t just delete registry keys and hope for the best.  Try and figure out what exactly is going on, because often times it’s easier to solve the why than the what.

SharePoint: Where to find things

Filed under: Links,SharePoint — phil @ 7:47 am

One of the first things I attempted to find was a forum or a mailing list that had a discourse of SharePoint related trials and tribulations.  I’ve been on the ActiveDir mailing list for many years now, and there is, daily, a wealth of information being shared by pros and novices alike.  I was hoping I could find something similar.  So far, no luck in the mailing list department.  Perhaps that will be something that I address in the future.  For now, however, I have found a lot of good blogs and websites of folks sharing the information I was looking for in a different format.

Word on the street is that SharePoint Joel is the world’s leading expert on SharePoint.  This is all hearsay, at least from my perspective, but what I’ve gleaned from his website so far has been invaluable.  Recently, he has indicated that he’ll be switching his blog over to things more personal and if you’re looking for SharePoint related topics, the new mecca can be found here:  I’ll be watching both sites for now.

Learning SharePoint 2010

Filed under: SharePoint — phil @ 7:46 am

Let’s start with a background.

I went to school for physics.  I discovered that I hated advanced mathematics.  I switched to computer science.  All of you in the know, stop laughing.

After school, I took a job as a systems administrator at a college.  Well, at a university.  Well, at a very good university.  I was a fresh out, and they asked me questions like, “Do you know Windows?”  And being that I’d built my own computers and installed Windows 95/98, and had logged in a few times to an NT domain, I said, “Of course!  I’m a windows expert!”

I believed that for all of about 4 hours my first day.

What I discovered very quickly is that I didn’t know anything about Windows.  What I did know was how to install a workstation operating system and software.  What I did know (but I didn’t realize then) was how to troubleshoot problems with the operating system and software.  What I know now (that I only realized fairly recently) is that the ability to troubleshoot, to see problems in an environment (ANY environment), identify them, categorize them, research them, and solve them… THAT is a skill.  One that far too few people actually have (but often claim they do).

But I’m not here to toot my own horn.  The opposite, in fact.  I want to paint a picture here for you, the reader, so that you understand where I’m coming from before you walk down the SharePoint path with me.  I have 10 years of Microsoft Windows and Active Directory experience.  I’ve built and upgraded and migrated Windows NT/2000/2003/2008 domains.  I’ve created robust group policy schemes.  I’ve deployed software.  I’ve dinked around on Cisco networking equipment.  I’ve imaged hundreds of computers.  I am capable of troubleshooting any of those systems.  I installed SharePoint 3.0.  Once.  And then never really used it.  Now you have the background.

I am now, currently, a SharePoint Administrator.  I interviewed for the position and told them, up front, that 1) I didn’t know anything about SharePoint, and 2) I didn’t think that would be a problem.  I have learned a great deal more about SharePoint in the last week than I knew a month ago, and a month ago, I’d learned a great deal more than I’d known initially.

This blog will hopefully outline my trials and tribulations, my goofs and gaffs, and my successes as I build out the SharePoint infrastructure here.  I’m not sure how anonymous this will remain, but for now, I’ll leave specifics out.

« Newer Posts

Powered by WordPress