6 Reasons Why Everyone Should Have An Enterprise Vault Lab

[Rob_Wilcox1]

One of the things that I am passionate about, and always have been in relation to technology, is to have a good lab environment setup.  This lab should ideally closely resemble your production environment.  I know it's not always possible to mimic a complicated Active Directory environment, to have multiple Exchange Server clusters, or even to have the same type of storage as is used in your Enterprise Vault production environment.  But that being said, with some careful planning and consideration any organisation can build a 'good-enough' lab; a lab which is good for 'most things'.

The labs purposes is of course to test things out.  The focus in this article is to test Enterprise Vault things out, but also hopefully, having a good Enterprise Vault lab will mean that you can test out Windows patches, Exchange upgrades and many other things too.  I also don't think that you should make the lab so complicated, and so big, that it becomes difficult to manage in it's own right.  A lab I think, should be kept as simple as possible.

Sometimes it is necessary to try to convince the 'powers that be' to invest money (and time) in construction, and on going maintenance of a lab, so in this article I'll give you 6 good reasons for lab usage.

Test Patches

By testing patches, I mean the whole slew of types of patches really.  This is everything from Windows, and Exchange patches, to Enterprise Vault patches, to storage-device patches too.  Testing of patches is something that you can control in a lab environment (because you can block Windows Update to the lab, or, just configure the machines not to apply the patches automatically).  Aside from the obvious 'did the patch break anything', I would recommend looking out for how long it took the patch to apply, and what happened after the machine was restarted (as there a significant delay before it was available again).

With patches comes 'regular' service packs, in other words those that come with Windows and Microsoft 'type' applications.  In a typical lab this would be Windows, SQL, and Exchange.  Enterprise Vault service packs are a whole different beast as we know.  They are more the 'full installation' again, rather than an 'upgrade' in the 'Microsoft' sense.  That being said all of these types of service packs can be tested, and should be tested, in the lab that you build.

Testing Upgrades

I'd like to distinguish patches and service packs from upgrades.  By upgrades I'm referring to whole new 'major' releases.  So you'd use the lab to test introducing an Exchange 2010 server in to your Exchange 2003 environment for example.  You'd use the lab to test the upgrade of Enterprise Vault from 9 to 10.  And so on.  As with patches you're looking for things that get broken, and also the time it takes, missing prerequisites, number of reboots and so on.

Try Optimisations

Applications like Enterprise Vault are often very customisable, and at the time that your production environment went live you may have gone for a conservative approach when it comes to customisations that you applied.  So in your lab environment, over time, you can test out some of those customisations and see the effects on the data that you have.  For example you could test out Storage Expiry or Collections, from the Enterprise Vault arena, you could test out CAS-To-CAS proxying from the Exchange arena, and so on.

Try New Storage

If you're getting new storage hardware it is always a good idea to thoroughly test it in a lab environment before deploying it in production.  Aside from the 'does it work', and 'is it quick' type of questions, you'll need to consider how you're going to monitor it, how you're going to back it up, and so on.  Having a lab environment means that you can try these things out and perfect them a little before using them in your production environment.

Configure and Test New Schedules

As data in your Enterprise Vault environment, including SQL, grows over time, one of the challenges that comes along is how to fit all the archiving and backing up that is needed to be done in one day.  One way to utilise your lab environment in this respect is to setup new schedules and see how they look.  Of course the amount of data in your test environment is unlikely to be anything like what you have in your production environment, but testing it in a lab is still a good idea because it gives you another level of validation of what you are going to eventually try to do in your production environment.  You can also keep track and add to your plan which services may or may not need restarting in order to pick up the changes.

Test New Policies

Alongside testing new schedules is the option to test new policies.  These may be to replace old ones that people don't want or like any longer, or, it could be that you want to introduce different categories of users, and give them different abilities/experiences.  For example you may want to introduce Vault Cache and Virtual Vault, but only to a selection of people.  You may want to change the shortcut content part of the policy to have more or less characters in it, and want to truly visualise what items will look like once they have been processed by the new policy.  You could test out rebuilding the old shortcuts, and see how long it is likely to take, and the impact on the environment of doing so.

Conclusion

These are just a few of the reasons why having a lab is a must.  A collection of older hardware can be used, or, it can be hosted in VMWare or other virtualisation technologies.  

I highly recommend reviewing and tweaking the above list, and using it to get your way .. and get an Enterprise Vault lab setup today!  Okay it might take you a bit longer than that (and Rome also wasn't built in a day!)  But if you start today and use tools and technics like the great Populate EV Lab tool from QUADROtech, in a very short space of time you'll have an excellent lab in order to do your experiments in!