“Pride goeth before a fall.” Proverbs 16:18
So last week I was all pumped because after a month or so of reading and discussion, I finally felt I knew a little something about SharePoint administration.
This week I learned how little.
The MOSS setup includes a single virtual machine with Server 2003 and a SQL Server database. In attempting to move the VM housing MOSS, the sysadmins found they could not migrate it because of a missing VM vmx file. Attempts to recreate the vmx file were unsuccessful, and the VM would not power-up after shutdown.
We prepared to recreate the farm by reconfiguring a new virtual server to house MOSS. Luckily, I asked my good friend and patient mentor Todd Klindt (@ToddKlindt on Twitter) for some advice.
Turns out I was mistaken in thinking that because the farm included only one box, and that machine (which housed central admin) was unavailable, that we would be unable to join an additional server to the existing farm. In other words, I thought we would need to create a new farm by provisioning a new server, recreating our web apps, and then reattaching the databases from backup.
Todd corrected me by explaining that the config dbs are stored within the SQL Server databases, and that once we told the new MOSS Server which SQL Server database to use, the web apps, configs, Alternative Access Mappings, and content would be available, a process similar to adding an additional WFE.
The config dbs WERE the farm, so as long as the dbs were intact, all of our prior configurations would be there.
Things we would have to check would be SSL certificate installation, host headers, and removing the old machine from the farm via Central Admin (since it will continue to show up under Servers in this Farm). Other issues might be specialized icons (like the .pdf icon for search results), and Forms Based Authentication.
Sys admins came up with one more way to try to revive the old box. It took four hours but we took the gamble, since there were some settings on the original server (such as the host headers and IIS settings) that we had not backed up properly. If we could get the old setup going, we could export them properly and then add commands to the backup script to back them up in the future. That would put us back at a point of a working system, and we’d be in much better shape.
I got a reprieve — it worked! The current box will still need to be decommissioned, but it is back to its working state before it was shut down. Now we can more gracefully add the new server to the farm, switch all the services to the new server, and remove the old box.
Thankfully nobody’s yelling at me. SharePoint Admin is not even in my job description – I’m the Applications Chick. But when I realized there was no SP Admin, and that we had no one on staff with any experience with SP Administration, I figured I’d better start learning something about it because my apps and my users depended on it.
When I said something along that line, the head sys admin asked, “So who’s job is it?” I told him the former junior sys admin was doing it. “So you’re saying it’s my job?”
“No, I’m saying it’s your new junior sys admin’s job. Funny, he’s the only one not here working this weekend.” We both laughed.
I’m guessing this means I’ll get to add that SP admin designation pretty soon – because it’s pretty clear nobody else wants it!
Cross training in SharePoint is almost inevitable, anyway. SharePoint integrates so heavily with other technologies, you really need to at least have a working knowledge of SQL Server, Exchange, Active Directory, MS Office, and networking to make sure you can figure out the origin of errors when they pop up.
Thanks goes to Todd again for his help. He didn’t know my fan-dom came with a 24-7 tech support contract! Only thing I can give him is a problem example for his Monday morning netcasts.
But you gotta work with your strengths, and being a good bad example is definitely one of mine.