Version History in ImageRight 4.0

When our company started out with ImageRight 3.5, adding annotations to documents was one of the big features that made the system easy to adopt. However, much like writing on a document with a pen, annotations couldn’t be undone individually. One had to be very sure they were putting the proper annotation in the right place, because once it was committed to the page there was no turning back.

One of the improved features that came with ImageRight 4.0 is the addition of version history with documents. This feature allows people with the appropriate permissions to view the history of changes made to a page. While regular users can see the history of individual annotations by view the properties of each, the version history allows the quick review of each set of changes and a previous versions can be promoted to be the current version in the case of errors. This has allowed me to help some users “roll back” changes, which has saved them time and made people a little more comfortable with experimenting with different uses of annotations.

For .TIF images it shows the annotation history and for non-image files (like Word docs or spreadsheets) complete copies of the changed files are stored.
This is an improvement over the 3.5 version where annotation history was maintained for the sake of being able to review who added what marks, but didn’t allow for any type of administrative “undo” of annotation that were made in error.

When it comes to .TIF documents, it is possible to create a “new” version of a document without making a visible change. It’s important to have an idea of the scenarios where these extra versions can be created in case you are tasked with doing some type of detective work regarding the history of a document.

Here are several examples of when a new version can be created without any visible annotations.

  • Adding an annotation and then deleting the annotation prior to saving or moving off a page
  • Clicking on a sticky note, without moving or modifying the content
  • Deleting a sticky note
  • Add a text box with no text and deleting it prior to saving or moving off a page

As people get more comfortable moving within ImageRight and using annotations, these actions will happen less and the true history of each document will remain pretty clean. The addition of this feature provides valuable details that are worth the hit in disk space taken to maintain the versions.

Advertisement

ImageRight and a Remote Desktop display bug

This week starts our official “pilot” roll out of Server 2008 RemoteApp. This is our planned replacement of Citrix for remote access to several of our regularly used applications. We are only using the Server 2008 (not R2) on the application server because our imaging application, ImageRight (version 4.3), does not support 64-bit. If you are planning on doing something similar, there is a minor display bug when access ImageRight v4 through the Remote Web Applications interface and it’s likely related to how the drop down menus are rendered using ActiveX. The problem is not repeated when one logs onto the server directly.


In the “File Open” menu, there are drop-down menus for choosing the drawer
and file type of the file you are looking for. In this example, the drawer selection defaults to “All Locations,” but depending on your personal settings, it may default to a particular drawer that is used most often.

When a user attempts to drop-down the drawer menu to select another option, the menu appears to snap closed quickly and does not allow a selection, making it impossible to switch drawers. (The File Type selection menu works fine.)

This display bug is not scheduled to be fixed in ImageRight version 4 of the software and it’s not a problem in version 5.0 according to ImageRight support. Meanwhile, the work-around is simple. Right next to the “File Open” tab, is a “Search” tab. The Search tab allows for more specific options to selected – down to page types and document descriptions. However, it all does the same basic features as the “File Open” tab.

In my office this isn’t a commonly used tab, we have another search tool that searches across other records databases at the same time, so I have to make sure to point out the issue to new users and provide the work-around information up front. While I’d like our remote access to ImageRight to be a seamless as working in the office, this display issue isn’t a showstopper.

Restoring ImageRight in the DR Scenario

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.

64-bit ImageRight support? – The "drivers" are in control.

The disaster recovery testing is touching more areas then I even though possible related to what options we can consider in our production and emergency environments. It’s bringing to light how interconnected software has become, and how those connections can sneak up on you, even when one is dealing with them everyday.

A basic premise of our recovery plan is to provide access to our recovered systems remotely, until we can make office space and desktop systems accessible to everyone. In order to keep things “simple” and provide the quickest possible up time, the plan calls for using Windows Terminal Services (aka “Remote Desktop Services” in 2008 R2) technology.

Due to the improvements in the offerings available directly by Microsoft related to remote access and the relatively small number of applications we need to make available, we determined that bringing terminal services up initially would be faster than recreating our Citrix environment during an emergency.

In conjunction with this (and the fact that we have only a small amount of remote use in production) we are currently planning to reduce licensing costs by only providing access using Microsoft products. Windows Server 2008 (and now R2) has many of the features we were looking to Citrix for in the past. While it’s possible for us to meet most of our needs with Server 2008, we’d much prefer to use 2008 R2.

While I was at the Vertafore Conference, one of my goals was to find out their schedule for 64-bit support. As one of our main enterprise applications, its important that it’s available on our remote access solution. Since I was unable to run the software on my 64-bit Windows 7 computer, I wanted know how far they were from addressing that.

Turns out, it all comes down to third-party drivers for peripherals. ImageRight works with several popular hardware vendors when it comes to scanners, including Kodak, Canon and Fujitsu. This allows customers to take advantage of more of the built-in scanner features that come with the hardware, instead of writing a generic scanner driver that could reduce the functionality native to the device. They also use the drivers to provide desktop features that allow end users to import documents directly from their PC.

Because of this, 64-bit support for the ImageRight software is directly related to how quickly scanner vendors make 64-bit drivers available. ImageRight claims that the makers of these key peripheral devices are complaining that Microsoft didn’t give them enough warning between Windows Server 2008 and the release of Server 2008 R2 regarding the official “death” of the 32-bit version of the OS to provide 64-bit drivers for all their devices.

ImageRight is planning to have support for 64-bit operating systems by the end of this year. We aren’t planning on a widespread upgrading of desktop hardware to 64-bit any time soon and will be able to wait without too much suffering. However, it does alter our plans for our remote access changes in the next 3-6 months. A disappointment for sure.

Also, the delay doesn’t help existing ImageRight clients or upcoming new ones that hope to run (or at least begin to test) an important software product on the most current hardware and operating systems available. An interesting domino effect that ends in needing to reconsider what I’ll be using for remote access during my recovery testing this month.

Looking Forward with ImageRight

Enjoyed my first full day at the Vertafore Connections Conference. I’ve gotten a chance to chat with some of the great tech support staff that I’ve worked with over the last year and reconnect with some people who have been on-site at my office for installations and training in the past.

I’m looking forward to a few of the new features in version 5.2 and hope we’ll be able to upgrade to that as soon as possible. The integration with Outlook 2007 is pretty slick, especially for people who aren’t the heaviest users of ImageRight.

There has also been a lot of discussion about virtualization and disaster recovery related to the components of the ImageRight backend. Even though ImageRight isn’t “officially supported” in a virtualization environment, quite a few organizations have had success with some or all components of it. We are running our testing version on VMWare and haven’t had any issues thus far. If we have more success with the disaster recovery testing project over the next few weeks, it might be something to consider as we look at ways to make improvements in our server infrastructure.

Vertafore Connection (IUG09) Conference

Today I’m heading out to Altanta to take part in the Vertafore Connections Conference (previously known as the ImageRight User Group Conference). This will be the 2nd chance I’ve had to participate in this conference and I’m looking forward to seeing what’s new in version 5 of ImageRight, learn how I can take advantage of virtualization to reduce the footprint of servers we have for the application, and get to meet some of the great support team that I only know only through email and phone conversations.

I’ll also be following Vertafore Connections on Twitter (hashag #VconX) while I’m there.

Stumbling Over AD Intergration in ImageRight

Friday night, I was responsible for a maintenance upgrade to our document imaging system, ImageRight. This upgrade was required to repair a potentially serious data corruption issue that was discovered by the vendor. We weren’t affected by the corruption at the time it was discovered but some functionality had been disabled as a work-around, so we had to schedule time to perform the fix.

First off, let me say that I really like the vendor and I like how the product works overall. However, we always seem to be the client who has issues that the vendor never seems to encounter before. It was almost refreshing when they called about the corruption issue and it wasn’t something we’d found first.

Friday morning, I had exchanged a few emails with the vendor support tech who was going to do the upgrade to firm up the planned roll-back procedures (for our change management documents) and to clarify any last minute items. He mentioned a known bug related to environments with ImageRight users that spanned multiple Active Directory domains, fondly referred to as the “AD dual domain bug” and how the upgrade shouldn’t be performed if we had an environment with those characteristics.

Yes, we have two domains. But no, we don’t have accounts that are used by ImageRight from the second domain. We confirmed those details and I mentioned in one of my reply emails that the AD bug had me a bit worried anyway. I was told my environment wasn’t going to be an issue based on their testing. (Okiedookie then.)

So away we went with the upgrade. That was the easy part. Then came the testing.

Exactly half the program worked – literally half. The program launches two windows when it starts – one window acts as the file manager, for searching and loading image files and the other is the image viewer. I could see and use the file manager portion, but the viewer never loaded, only returning an error that was cryptic overall but referenced active directory about 15 times.

Um, yeah.

So they uninstalled and reinstalled just to make sure some random DLL wasn’t left behind or something. But that didn’t solve the problem. I chilled out on hold for a while. It was already after 7pm here on the west coast, so I felt a little bad for the tech on the east coast. “Are we sure this isn’t a different manifestation of the AD bug?”, I asked.

I chilled out on hold for a while longer while the support tech consults some developers on his cell phone. No, it shouldn’t be the AD bug, we are getting an error “too soon” in the loading of the program, but there is a hotfix for that bug that should be released on Monday. A developer was working on getting a copy for us now if we wanted to try that.

Why not? It’s already broken, might as well toss one more thing at it before we roll everything back. Sure enough the hotfix did the trick, avoiding a roll-back and saving me another late night at the office. I wasn’t surprised that it was yet another instance of something no other client they have has ever experienced.

I’m not sure how I feel about always being the “one-off” case, but it always seems to work out fine in the end. Though I’m thinking of framing my “I’m a bit worried about the AD bug” email that I sent out before we even began.