Best Practices for patch/rollback on Windows?

[Former Member]

All,

I have been working on BO XI with UNIX for some time now and while I am pretty comfortable with managing it on UNIX, I am not too sure about the "best practices" when it comes to Windows.

I have a few specific questions:

1) What is the best way to apply a patch or Service Pack to BO XI R2 on a Windows envt without risking a system corruption?

- It is relatively easier on UNIX because you don't have to worry about registry entries and you can even perform multiple installations on the same box as long as you use different locations and ports.

2) What should be the ideal "rollback" strategy in case an upgrade/patch install fails and corrupts the system?

I am sure I will have some follow up questions, but if someone can get the discussion rolling with these for now, I would really appreciate!

Is there any documentation available around these topics on the boards some place?

Cheers,

Sarang

[Former Member · Accepted solution]

Hello Sarang,

One solutions that I know works for a lot of my customers is virtualization. Before a fix pack or service pack is installed, they stop all BO XI services, take a backup of the database and FRS and snapshot the VM.

If anything should go wrong, it's relatively easy to rollback to the previous situation. However, this means that the problem should either come up while applying the fix/service pack, or shortly afterwards; as rolling back would mean a potential loss of data (reports, universes, ...).

To avoid unexpected issues, I would advise you to alway extensively test any fix/service pack on a separate, if possible identical environment. Due this for as long as you need to feel comfortable with the update. Meanwhile, keep an eye on the forums to see if others are experiencing any issues.

Remark: the snapshot could of course be replaced by a system backup when you're working with a physical system instead of a VM, but reverting to a snapshot is far easier (and faster) than restoring a backup.

Hope that helps.

Kind regards,

Kristof

[Former Member · Accepted solution]

Hi Kristof,

Thank you for your inputs. I think your idea of using a virtual environment makes a lot of sense. I am not sure at this point if I will be able to set up a virtual infrastructure for testing patches and upgrades etc, but that is the route I want to take.

Working with physical systems, how can we be sure of no windows registry corruption if I were to "unistall" or "rollback" specific patches on the box. I think it would still need a complete system image (snapshot) that can be restored on the physical box if things were to get corrupted. Is that assumption correct?

If anyone else has other approaches/strategies to share, it would be great!

Thanks,

Sarang

[BasicTek · Accepted solution]

This is unofficial but usually if you run into a disabled system as a result of a patch and the removal/rollback does NOT work (in other words you are still down).

You should have made complete backups of your FRS, CMS DB, and any customizations in your environment.

Remove the base product and any seperate products that share registry keys (i.e. crystal reports)

Remove the left over directories (XIR2 this is boinstall\business objects\*)

Remove the primary registry keys (hkeylocalmachine\software\businessobjects\* & hkeycurrentuser\software\businessobjects\* )

Remove any legacy keys (i.e. crystal*)

Remove any patches from the registry (look in control panel and search for the full patch name)

Then reinstall the product (test)

add back any customizations

reinstall either the latest(patch prior to update) or newest patch(if needed)

and restore the FRS and CMS DB.

There are a few modifications to these steps and you should leave room to add more (if they improve your odds at success).

Regards,

Tim

[Former Member · Accepted solution]

Hello Sarang,

Tim's response certainly can be used as an alternative, although it is more cumbersome than restoring a backup taken before the patch. Also, if you do follow this scenario, make sure you do not reset the existing CMS repository when installing BOE again.

Some hints regarding backups:

- make sure all services are down before starting the backup

- always take offline backups for your database

- take synchronized backups. In other words: do not start the BOE environment again before the backup of your CMS, FRS and server is complete.

BO XI 3 offers the possibility to check your repository for consistency. I highly advise you to run this after performing a restore.

Kind regards,

Kristof