It seemed like a good idea, and it still seems like a good idea when it works, but when my combination of Data Protection Manager, Hyper-V, and iSCSI gets grumpy, it gives me ulcers.
My recent issue started, as it usually does with this setup, with a power outage. The power went out, and when it came back on all the servers came back up properly. “No Problem”, I thought, however a little bit later I noticed that DPM was having issues backing up the virtual servers on one of the virtual hosts. I tried to kick the backup jobs off manually, but they failed with a VSS error of event ID 12305, “Volume/disk not connected or not found” and that the VSS provider was in a “bad state”. I tried some of the easy things that I found on the ‘net but to no avail. I figured I’d reboot the box and that it would “figure itself out “when it came back up (which is often the case when my DPM backups delightfully start bombing out on a virtual host). This time however, the server came up and my iSCSI virtual machines were gone, unlisted in the Hyper-V manager. Despite the fact that Hyper-V has delisted virtual machines on me several times in the past as well, it never ceases to cause me to question my career choice when it happens.
Investigating, I saw that the iSCSI drive along with the virtual disks were there so my hope was that the VHDs were okay. When Hyper-V was trying to add the virtual machines it was kicking out an error along the lines of an OID that couldn’t be found. Distressed, I decided to just recreate the virtual machines from the VHDs (not a first for me either), however I made the fortunate mistake of letting Hyper-V store the virtual machines in the default directory on the system partition. The first two machines started up fine, but the third kicked out an error that it couldn’t write the memory file. I had forgotten that Hyper-V keeps a swap file of the memory for the virtual machine and I had run out of space for such files on the system partition. I figured that I’d have to recreate the virtual machines, again, but in their original directories on the iSCSI drive. Before I went through that work again though, I figured I would take a shot at modifying the XML config for the servers that I had just created.
It was then in the Hyper-V ProgramData folder that noticed something peculiar – the links to the original non-operational virtual machines weren’t working. When I pulled the directory listing I found them pointing at ‘F:’, but there was a different drive on ‘F:’ and the virtual machine iSCSI drive had been moved to ‘H:’. It turns out that after the power outage the server had decided to snag an unassigned iSCSI drive that was on an attached Netgear ReadyNas box and assign it to ‘F:’. The Virtual Host had worked fine through the week because the drive mapping didn’t take affect until after I rebooted the server. After reassigning the drives my Hyper-V and DPM are happy again, but I’m sure they’ll get back at me eventually.
I notice that Blackbaud now has a utility out that handles Supervisor password resets without going through the faxing rigamarole, but when I had to do this I don’t know if that would have been a big help anyway as my customer A) Needed supervisor access to Raiser’s Edge right away and B) They had fired the one employee who had both supervisor access and was the Blackbaud support user.
The two things I did have though was administrator access to the Raiser’s Edge MS SQL database and the SQL Server Management Studio. My quick and dirty fix was to open the database (re7), open ‘tables’ and then find the ‘USERS’ table (dbo.USERS). I then right-clicked the table and then chose ‘open table’. There is one other thing that’s needed for this procedure at this point: a password that is known. In this case I had the one’s below:
I’ll point out that I put no energy into checking out the hashing code used (i.e., can the PASSWORD field be blank? Are the passwords hashed the same on every RE install?, etc.). In this case all I did was copied the PASSWORD hash field from an account whose password was known to the Supervisor PASSWORD field. (It goes without saying that I also backed the database up first (right click the database->tasks->Back Up…))
This is my definitive guide on migrating from 32 bit Windows SharePoint Services 3 to SharePoint Foundation 2010 (64 bit only, oof!). It’s not quite as definitive as I would like as I barely had time to work this through once, let alone multiple times:
- I changed the user account that runs WSS3 from ‘NETWORK SERVICE’ to a domain account (though I’m unsure if this step is required). I originally did this when trying to restore the 32bit WSS3 onto the 64bit box and then using 64bit WSS3 to try and upgrade it. Don’t do that by the way. Anyway it made working with the database easier on the whole anyway.
- Backed up the SharePoint content database, called STS_servername_1 in my case. (This server used the ‘Windows Internal Database’, an extra crippled version of the already crippled SQL express. I had installed the SQL 2005 tools on there for a different project so I used the ‘SQL Server Configuration Manager’ to change the service argument to add “;-T7806” and I then used the SQL management studio to do the backup).
- Installed 64bit Sql Server 2008 express on the new 64 bit server (I named the main instance the same as the instance on the 32bit box, not sure if that matters)
- Installed SharePoint Foundation on the new 64 bit server (it automatically set itself up in the SQL instance I installed).
- Restored the content database to the new server (again, using the management studio; I know that it can be done through the command prompt but I like the visual feedback).
- Within the Central Administration site on the new server I went to ‘Manage Content Databases’, clicked on the preinstalled content database and removed it in the subsequent interface. This step removes the content linked to ‘/’ so that the restored database can go there.
- Added the restored database to the farm using stsadm. (in our case: stsadm -o addcontentdb -databasename STS_servername_1 -databaseserver newserver-url http://newserver/)
- Upgraded the content database using the ‘upgrade-spcontentdatabase’ command within the Sharepoint PowerShell.
- The content should now show up when you pull up http://newserver/ , but to complete the upgrade (and keep the content database from showing as ‘mostly upgraded’ or something along those lines) I had to upgrade the view under ‘Site Settings’ within the Sharepoint site and then going to (I believe) ‘Visual Upgrade’.
Obviously our setup is fairly simple with one server driving the whole ‘stack’. Our content is also fairly static (it didn’t matter that the database backup that I was working with was a day old). Your results, of course, may vary (but will probably do a sight better than trying to put something together from the amalgamation of websites that only convey one piece of the puzzle!).
Part of my motivation for patching up the system was so that we would be running a version of MAS 90 that was officially supported on 64bit Windows 7. An odd issue that’s possibly related to compatibility cropped up today though.
When going into one of our companies, MAS would crash/stop responding when going in to “reprint journals” under the general ledger reports. It worked for every other company AND even worked for that same company if the report-program was run from a 32 bit system.
The big clue was that the UI for the report never launched after clicking OK for the accounting date, which usually tells me that an ‘output issue’ exists. After comparing the settings under company maintenance it turned out that the one that didn’t work didn’t have “Use Workstation Default Printer for STANDARD Report Setting” or “Form Code” checked. After checking those two boxes and accepting the changes “reprint journals” began working for 64 bit systems.
I recently decided to be brave and install a hotfix rollup/service pack to our MAS 90 4.3 install. I believe we were on patch 3 and I would be installing patch 20. My goal was to clear up some oddball Windows 7 issues that we were having (the exact nature of which I cannot recall unfortunately).
After installing the patch everything looked okay. It appeared that the client upgrade was somewhat optional since it only upgraded the help files (though I did it anyway just to be sure), and when opening some of the companies in the database I got an unexpected upgrade notice (unexpected since the system was patched and not upgraded):
For all but one of the companys, getting this “Data files have not been converted for this company” message wasn’t an issue. However for one of the companies in our database we would receive this error, go through ‘Company Maintenance’ to upgrade it, then receive a message that said that there was nothing to upgrade, but then get the “have not been converted” message again when trying to go into the database.
What was odd was that under ‘Company Maintenance’, the ‘Common Information’ module for the company was listed as version “4.09” (which so far as I know, wasn’t even a production release version of MAS 90). Every other module in every other company was listed as “4.30”. I am unsure as to how MAS works in the background, but when I looked at the files through a hex editor it did appear that they reporting that they were version “4.09” (however in hindsight it would appear that this value was ‘pushed in’ rather than ‘pulled out’ of the tables). Ordinarily it would probably be worth restoring the data and trying to figure out what went wrong, but for reasons I’ll not get into the application had already been used for more than two weeks (outside of that company of course).
As luck would have it, I needed to perform some operating system tests a couple weeks earlier and had a test copy of the virtual server that hosts our MAS installation and the data was from before the upgrade. I tried copying the tables over and a couple other little things, but after nothing worked out I decided to try and upgrade the test copy of the database to see why the upgrade to that company failed, only…it didn’t. It worked fine. I then copied over that copy of the company over to the production MAS.
What happened next was rather odd, but MAS is a bit of an odd product. The version number was still reported as “4.09”, but in poking around I opened the ‘Copy’ utility under ‘Company Maintenance’ with the thought that I would copy another company’s ‘Common Information’ set over to see if the version stayed the same. I thought better of it again (this wasn’t the first time I mulled it over) and I canceled out and then for whatever reason the version number for ‘Common Information’ was properly reported and the upgrade error went away.