A lot of the time people might think that testing an environment, any environment, is something that the software company itself should be doing. This to some extent, is right. And to some extent it’s wrong. In this article we’ll see five different considerations which are needed and why testing your own environment is critical to having a healthy Enterprise Vault environment.
Active Directory is a complicated beast. It’s simple in a self contained unit, but when it’s spread across multiple geographies in multiple data centres all over the world it becomes complicated due to it’s size and reach. This is sometimes further complicated by having different versions of Windows taking part in the provision of Active Directory roles and services.
The structures of user group, organisational units and so on, are all unique to you. It is unlikely that anyone else names their service accounts, user accounts, and OU structure in exactly the same way that you do. Do your ‘super users’ use a regular Windows account, or do they have a separate administrative account? How much power do those accounts have on the network, and are they simply user accounts or are they mail enabled too?
One of the other things to consider when it comes to Enterprise Vault and Active Directory is to assess the load that is placed on the Active Directory servers during archiving, PST ingestion, expiry and other Enterprise Vault ‘heavy’ operations. Active Directory servers which may also be servicing user requests might not be best suited to also be used by a busy Enterprise Vault server.
Your Exchange environment is likely to involve far fewer servers than the roaming wilds of your Active Directory estate. But it might still be sizeable, and might be on ‘complicated’ high performance hardware. Things like Microsoft clusters and replicated storage might come in to play. When you are doing Enterprise Vault related activities or assessing the amount of data that you can archive in a particular window, having the same or similar hardware is going to help you get this piece of the puzzle right. Of course, in many environments, it’s just not possible to have that sort of hardware in a test lab. You can however in some situations, have an in-production pilot area/server to do final testing on.
The main sorts of things to test with regards to Enterprise Vault and your Exchange environment is the affect of Exchange and Windows patching on the environment. In the past this was critical with things like the Enterprise Vault Outlook Web Access extensions needing careful attention to detail when it comes to version numbers. That’s not so bad now that the way that Enterprise Vault interacts with Exchange (for OWA) is different than the ‘old way’ of editing control files.
Testing of Support Processes is also something that should be done from time to time. This might include deliberately breaking parts of Enterprise Vault and then testing support staff in the identification and fixing of the issues. At the very least you’ll be able to see things first hand before end-users start reporting issues, and you’ll be able to do things that you might not be able to do in the production environment because of users sensitivity to not having access to archived data.
We mentioned earlier that Exchange hardware is likely to be unique to your organisation, the same is true of the hardware running your Enterprise Vault environment. In particular is the interaction between Enterprise Vault, SQL Server, and underlying disk subsystems used by the Vault Store partitions. Again it might be something that you can entirely replicate in a test environment but it is a must to be able to review and adjust what happens through various Enterprise Vault processes like archiving, expiry, PST ingestion, index rebuilds and so on. How does your hardware hold up to those type of operations when a user request to build Vault Cache also comes in during that time frame? Does the hardware respond well, or is it struggling from a performance perspective?
A few years ago I remember taking this screenshot, and being proud:
I had worked out how to use Windows XP Mode in Windows 7 in order to run Internet Explorer (and Microsoft Outlook) of different versions side by side on the same computer.
What’s my point?
Users, unless you’re working in a super-locked down environment, are likely to have all sorts of versions of all sorts of browsers and Office-ware applications installed. You, when looking at your Enterprise Vault environment should be considering how to take those sorts of things into consideration. Do the policies you’ve chosen within Enterprise Vault work with the different versions of Enterprise Vault? I know one customer I have had dealings with uses a version of Outlook on many desktops (10,000’s) that is so old it doesn’t support PSTDisableGrow.
Users also span a number of geographies and cultures. A dictated, strict policy might ‘sound’ good from an IT point of view, but will end users embrace it, or will they resist the way that IT pushes all sorts of ‘rubbish’ on to them?
It is almost impossible to build a lab environment which completely mimics your production environment. For one thing you won’t have the users never mind the hardware or budget to build something that matches. Looking after an environment like that would also be just about impossible. You’d need double the amount of staff resources if it were to become a reality.
That being said, a lab is essential. I’ve written before why you need to have a lab.
In summary then we’ve seen why it is important to test Enterprise Vault in your environment. You should be doing this in a lab environment, as well as in your production environment. Don’t get me wrong I’m not suggesting you have miles and miles of red tape and processes making it just about impossible to do any kind of change in any kind of sensible time frame. I am suggesting though that you need to test carefully how things work, for you.
How do you do your system and environment testing? Let me know in the comments below.