PacITPros will be having the September meeting tomorrow night at 6:30pm.
There is quite the line up of topics - Ed Horley, Microsoft MVP in Enterprise Security, will be presenting on Windows Server 2008 R2 and Windows 7 as a "Better Together" story. Specifically, what items are available only from Windows S2K8R2 with Windows 7 and how they would be compelling to use.
I'll be doing a short presentation of what's new with Microsoft certification tracks (specifically info about the MCITP and MCTS certifications) and Kathy Jacobs, Microsoft MVP in OneNote, will be doing an overview of some of the cool new features in Office 2010. Plus with the VMWare conference going on right down the street, there is sure to be a lot of chatter about what's going on over at the Moscone Center.
Monday, August 31, 2009
Tuesday, August 25, 2009
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.
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.
Monday, August 24, 2009
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.
I'll also be following Vertafore Connections on Twitter (hashag #VconX) while I'm there.
Saturday, August 22, 2009
Disaster Recovery - But for Real
This past week I've been doing the preliminary work (installing servers mostly) to get ready for our scheduled disaster recovery test. I expect that we'll learn a lot about our existing plan and systems documentation and will be looking to make some changes that will make any need for a large recovery faster and more effective.
Meanwhile, I'm managing some real disaster recovery, but on a smaller scale. A few weeks ago I posted about the need to upgrade our ImageRight installation to resolve a bug that could cause some data loss. The ImageRight support staff worked hard to run the preliminary discovery/fixing of the image files and database, followed by performing the upgrade.
Not long after, I got an email from someone in another department asking me to "find" the annotations added to a invoice that seemed to have gone missing. She was assuming that since some temporary help had worked on the document, a user error had been made and a "copy without annotations" had been introduced. I could recover the annotations by looking through the deleted pages and at previous versions of those pages.
However, what I found was a bit unexpected. I found a history of changes being made to the document, but no actual annotations visible. Curious.
So I opened a support ticket. After several remote sessions and research, the ImageRight team was "nearly positive" (they need more testing to confirm) that the process run before our last upgrade to correct the potential data loss, actually introduced a different kind of data loss. The result is that the database knows about the affected annotations happening, but the physical files that represent the annotated versions had been replaced with non-annotated versions.
We do have the logs from the original process, so it was just a matter of ImageRight Support parsing that data to generate a list of files that were changed. Now we begin the task of recovering those files from tape.
Our Sr. DBA had been working on side project that loads all our backup catalogs into a database so we have a comprehensive reference from all backup servers to identify what tapes to recall when people ask for recoveries. That project is proving its worth this time around, since we need to locate and restore over 1000 files. He also needs to cross referencing them to the individual documents accessible via the desktop client so we can do a visual comparison to any special cases and to provide a record of which documents were affected in a format that's understandable to everyone else, in case additional concerns come up after we repair the damage.
Meanwhile, I'm managing some real disaster recovery, but on a smaller scale. A few weeks ago I posted about the need to upgrade our ImageRight installation to resolve a bug that could cause some data loss. The ImageRight support staff worked hard to run the preliminary discovery/fixing of the image files and database, followed by performing the upgrade.
Not long after, I got an email from someone in another department asking me to "find" the annotations added to a invoice that seemed to have gone missing. She was assuming that since some temporary help had worked on the document, a user error had been made and a "copy without annotations" had been introduced. I could recover the annotations by looking through the deleted pages and at previous versions of those pages.
However, what I found was a bit unexpected. I found a history of changes being made to the document, but no actual annotations visible. Curious.
So I opened a support ticket. After several remote sessions and research, the ImageRight team was "nearly positive" (they need more testing to confirm) that the process run before our last upgrade to correct the potential data loss, actually introduced a different kind of data loss. The result is that the database knows about the affected annotations happening, but the physical files that represent the annotated versions had been replaced with non-annotated versions.
We do have the logs from the original process, so it was just a matter of ImageRight Support parsing that data to generate a list of files that were changed. Now we begin the task of recovering those files from tape.
Our Sr. DBA had been working on side project that loads all our backup catalogs into a database so we have a comprehensive reference from all backup servers to identify what tapes to recall when people ask for recoveries. That project is proving its worth this time around, since we need to locate and restore over 1000 files. He also needs to cross referencing them to the individual documents accessible via the desktop client so we can do a visual comparison to any special cases and to provide a record of which documents were affected in a format that's understandable to everyone else, in case additional concerns come up after we repair the damage.
Our current plan is to have this resolved by the end of next weekend, but this is something that needs careful handling since we don't want end users to have any doubt about the integrity of the system, which I still have total confidence in once we sort this out. Thus, I'm happy to spend the extra time making sure no other issues are introduced.
Plus I need some time to find our DBA some really nice coffee for his efforts.
Wednesday, August 19, 2009
Dusting off the Disaster Recovery Plan
This week, I started testing our department's disaster recovery plan. The goal is to use the contents of our existing "disaster recovery box" that we keep off-site combined with our current backup tapes to restore some key parts of our infrastructure.
Success or failure will be measured by what road bumps we encounter and most importantly, our ability to work around them using only the resources in the box. If I have to go "outside the box" for some critical piece of software or some undocumented configuration detail it would be a black mark in our preparations that needs to be remedied.
Our testing scenario includes the domain, Exchange, the document imaging system, the financial system, the primary file server and the time card application. We are also going to provide remote access to restored applications so staff from other departments can test out the results and give us feedback on changes that could improve the end-user experience during this type of event. As an added bonus, we'll be able to try out Server 2008 R2 Remote Desktop Services.
In the last 6 months we started using VMWare ESX to consolidate some of our servers in production, but none of the machines needed for this scenario are virtual yet. I will be doing "classic" restores where the OS has to be installed before restoring our data from backup tapes. However, we are using VMWare to host several of the machines in the disaster lab, so I will be able to save time by cloning my first installation of Windows Server a few extra times before installing specific applications.
Depending on how this project goes, I'd like to see us take more advantage of virtualization within our disaster recovery planning and maybe start looking into backup solutions that are easier and faster than tape.
Success or failure will be measured by what road bumps we encounter and most importantly, our ability to work around them using only the resources in the box. If I have to go "outside the box" for some critical piece of software or some undocumented configuration detail it would be a black mark in our preparations that needs to be remedied.
Our testing scenario includes the domain, Exchange, the document imaging system, the financial system, the primary file server and the time card application. We are also going to provide remote access to restored applications so staff from other departments can test out the results and give us feedback on changes that could improve the end-user experience during this type of event. As an added bonus, we'll be able to try out Server 2008 R2 Remote Desktop Services.
In the last 6 months we started using VMWare ESX to consolidate some of our servers in production, but none of the machines needed for this scenario are virtual yet. I will be doing "classic" restores where the OS has to be installed before restoring our data from backup tapes. However, we are using VMWare to host several of the machines in the disaster lab, so I will be able to save time by cloning my first installation of Windows Server a few extra times before installing specific applications.
Depending on how this project goes, I'd like to see us take more advantage of virtualization within our disaster recovery planning and maybe start looking into backup solutions that are easier and faster than tape.
Subscribe to:
Posts (Atom)
-small.jpg)
