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

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.

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.

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.