Our document imaging system, ImageRight, is one of the key applications that we need to get running as soon as possible after a disaster. We’ve been using the system for over 2 years now and this is the first time we’ve had a chance to look closely at what would be necessary in a full recovery scenario. I’d been part of the installation and the upgrade of the application, so I had a good idea of how it should be installed. Also, I had some very general instructions from the ImageRight staff regarding recovery, but no step by step instructions.
The database is SQL 2005 and at this point it wasn’t the first SQL restoration in this project, so that went relatively smoothly. We had some trouble restoring the “model” and “msdb” system databases, but our DBA decided those weren’t critical to ImageRight and to let the versions from the clean installation stay.
Once the database was restored, I turned to the application server. A directory known as the “Imagewrt$” share is required as it holds all the installation and configuration files. We don’t have all the same servers available in the lab, so we had to adjust the main configuration file to reflect the new location of this important share. After that, the application installation had several small hurdles that required a little experimentation and research to overcome.
First, the SQL Browser service is required to generate the connection string from the application server to the database. This service isn’t automatically started in the standard SQL installation. Second, the ImageRight Application Service won’t start until it can authenticate its DLL certificates against the http://crl.verisign.net URL. Our lab setup doesn’t have an Internet connection at the moment so this required another small workaround – temporarily changing the IE settings for the service account to not require checking the publisher’s certificate.
Once the application service was running, I installed the desktop client software on the machine that will provide remote desktop access to the application. That installed without any issue and the basic functions of searching for and opening image files were tested successfully. We don’t have the disk space available in the lab to restore ALL the images and data, so any images older than when we upgraded to version 4.0 aren’t available for viewing. We’ll have to take note of the growth on a regular basis so that in the event of a real disaster we have a realistic idea of how much disk space is required. This isn’t the first time I’ve run short during this test, so I’m learning my current estimates aren’t accurate enough.
Of course, it hasn’t been fully tested and there are some components I know we are using in production that might or might not be restored initially after a disaster. I’m sure I’ll get a better idea of what else might be needed after we have some staff from other departments connect and do more realistic testing. Overall, I’m pretty impressed with how easy it was to get the basic functionality restored without having to call ImageRight tech support.