Experienced little things-2 or "What should I do with all this mail"?

The continuation of the series of posts on "experimental little things", on the nuances, examples, scripts, solutions to various interesting or routine tasks that I had to deal with over the years of working as a windows admin.
The pilot issue dealt with the task of “determining which user works for which computer”, today we will focus on the problem of growing mail databases and one way to solve it on the MS Exchange server.

Formulation of the problem

The essence of the problem was trivial - VERY BIG VOLUME of mail databases. At that time, it was about 800 GB lying on one server (for the sake of fairness, I must say that the server coped with the load at the very least, although the 32-bit nature of Exchange 2003 hindered it greatly).

The specifics of the company’s work imposed these limitations:

• the vast majority of users need access to their old letters, preferably in sorted form (counterparties, cities, size of warts on the nose and other subjective criteria)
• the management longed to be able to recover the mail of its employees if it was accidentally \ accidentally deleted, even if it was hard and "without recovery" if the computer crashed, etc.
• administrators wanted the mail backup not tossing and turning like a pregnant elephant for 30-40 hours, but could be performed at least overnight
• data safety, protection against deletion, was most important, the leadership was panicky afraid of losing “something important” .
• MS Exchange 2003 and Outlook 2003 worked for the company. It was already purchased, but for various reasons MS Exchange 2007 was not implemented, as a result of which the conversation about upgrading to 2010 was met by friendly misunderstanding and complete unwillingness to spend quite a lot of money on itself.

Monsieur knows a lot about perversions, or solutions

Strategically, the solution to the problem was generally clear - you need to enter quotas for mailboxes (it can be differentiated depending on the department, user needs, etc.) and transfer old letters to archives. The whole question was how it is better (for admins) and more convenient (for users) to do. There were several options, and I began to work them out "on the cats."

• The simplest thing was to banally force everyone to delete old mail, citing the fact that the mail client is not for data storage, but for operational correspondence. And if necessary - get the necessary letters from backups. It immediately became clear that the method was unpromising, saying that it was met with aggressive misunderstanding from all users, including the management, and the process of getting out of the backup was incredibly dreary and long, and the situation when a person VERY URGENTLY needs his archive for 2006, was not so rare.
• Rejecting the first impulse, I tritely merged all the old letters into local PSTs and set up auto-archiving using Outlook. There were more minuses than pluses: mail was on workstations, it was unprotected from a burned-out HDD, and the archives could not be accessed via the WEB interface (giving everyone-all remote RDP access to their computers was not allowed by the SB department, and in my opinion, it did the right thing )
• Then I fiddled with the script "once a week to go around the computers on the list and merge PST into a folder on the server" - it was fun, I got plenty of it, especially with cunning Outlook, which in the open state SO locks the PST file, so you can’t copy it while Outlook will not close.
• The next logical step was the transfer of PST archives to the centralized storage, to the network. Here the problems started with the fact that if the network was cut off at the time of opening \ working \ closing Outlook, then the user got a 50% chance the next time he got a window “checking for incorrectly closed PST”, which could hang from 5 minutes to an hour, depending on PST sizes. And even if you close your eyes to all this, still there was no way to let people work with archives remotely.

What happened in the end.

Finally, I remembered the law of the inventor of the bicycle, and decided to manually repeat what we already did, but in the Exchange 2010 - Outlook 2010 bundle (for those who don’t know, I recommend reading the documentation, such functionality as archive mailboxes appeared in this version of Exchange, and, according to reviews of friends, it works pretty well). The result is this:

1. First migrated to Exchange 2007 , since there is such an opportunity - a sin to miss. Separately tinkering configured OWA through ISA. It became a little easier, because 2007 64-bit and understands a lot of “RAM”, something, but I’ve never regretted this good for servers.
2. For each user who did not fit into the predefined quota, a phantom user " Archive username " was created with the alias arc.username , and he accordingly also had a mailbox. For a change, I made all of them Equipment type, so that it can be guaranteed to be distinguished from ordinary workers in the future. Accordingly, the rights were distributed so that the ordinary user had full access to the box of his "phantom"
3. He hid all phantoms from the Global Address List , "for the sake of order," and grouped them into separate Database in the Storage group, where Circullar logging is enabled and which lie on a large, large RAID partition.
4. The so-called Storage Group also included the so-called SB boxes, where the logging of especially important users merged.
5. Support was connected to each user by its phantom colleague in Outlook, and all the mail that fell under the archive criterion was pumped to the phantom box .
6. Anyone who has an archive can now remotely dig through it through OWA, a little instruction has been written on this subject for those who are especially dull.
7. The size of the "operational" Exchange databases, those that toss and turn every day and backup 3 times a week, decreased to an acceptable 200 GB
8. Archive databases are backed up less often, along with SB boxes, once a week, on weekends. We’re doing just fine in time (and after updating the version of the backup server, they began to do a full backup of all the mail in 25 hours).

The minus of the idea was that the user had to transfer letters to the archive by hand (unlike, for example, the Exchange 2010 – Outlook 2010 bundle, where this can be configured automatically), guided by Exchange notifications about reaching the quota threshold. But on the other hand, it became even a plus, because with manual migration, users just sort their mail as they see fit, according to them only by guided criteria.

To be continued .