Forum Discussion

sujith_poojari's avatar
sujith_poojari
Level 4
11 years ago

Migrating all PSTs into one account

Hello All,

 

I am currently deploying an EV 10.0.4 solution for Exchange 2007 for arround 3500 maiboxes.

 

The customer requires to migrate all the PSTs in the Enterprise Vault stores. Due to the vast number of user mailboxes, it would be diffcult to catch hold of all the users and persuade them to upload their PSTs. Even a server driven migration would be a hurdle since the users are located in different geographical locations and locating their PSTs from their desktops.(also Remote registry service is turned off due to compiance issues)

 

The organization has a desktop backup solution which backups up all data in desktops and stores them in a central location.

I was wondering if it would be advisable to create a seperate PST mailbox account and migrate all the PSTs from the backup solution to the Archive of this pasrticular account.

Would there be any challenge in doing so? 

 

Thanks in advance for the replies.

 

Enterprise Vault
Information Governance
Installing
Integration
Windows Server (2003-2008)
  • GertjanA's avatar
    GertjanA
    11 years ago

    I would at least prevent adding new PST's and/or prevent adding data to the PST's.

    The goal of a backup in general is IMHO being able to restore. Archiving all PST's into 1 archive does not really allow that.

    If I were in your shoes, I would read up on PST migration. I would do the following:

    Create a GPO that prevents adding items to PST-files, and to create new PST file. Set registrykey to allow EV client to work as expected.

    Configure PST locations, Create a PST Migrator task, configure that.

    Create a new PST policy that has under migration the tick at 'allow pst submission'. Set Create shortcuts at 'this folder under root' = Archived PST file, uncheck 'merge folder structure, uncheck 'restrict shortcuts by age'

    Create a new provisioning group, keep existing policies and settings, except for the PST migration, use the new one. Add some users. run provisioning, sync those users mailboxes. close/open Outlook. a new button will be available in Outlook called PST migrations. The EV-client will find PST's and add those here. They are uploaded to the EV server in parts of 10MB. Verify in Personal Store Management in Console if users start appearing.

    When PST's are showing, apply GPO to those users.

    If you want to allow them to keep using PST files, it is going to be very difficult to keep up with new added data to the PST files.

    It is my opinion that you either import the pst's in the belonging users archive, and stop them from using pst's, or you allow pst's and do nothing with them. A reason for keeping PSt's might be users require access to their old data, then you might be looking at Vault Cache. (local copy of the archive)

    I see you're a partner, you might want to discuss this with your EV SE.

  • GertjanA's avatar
    GertjanA
    Moderator
    11 years ago

    Hello,

    How are you going to give the users access to the archive with the PST's? Keep in mind users will always state there is information in the PST they need. (true or not true)

    What I would do in your case is Client Driven Migration. Read on that in the Admin Guide. There is also a whitepaper on that : https://www-secure.symantec.com/connect/articles/new-whitepaper-pst-migrations-enterprise-vault-10

    I've been using this, and it works great. The only requirement is that the PST's are locally stored. You can do this in steps (granularly), with the PST task sending messages to the users. These messages can be customized! So you can inform your users, point them to an intranet site etc.

    I do advise to import the PST's into the correct archives. Imagine a recpetionist being able to find classified old mails of the CEO in this 'shared' archive......

    Or, look at QuadroTech PST Flightdeck. Really excellent tool for just your situation!

  • sujith_poojari's avatar
    sujith_poojari
    Level 4
    11 years ago

    Users will have access to their PSTs in the local machine. We are simply migrating the content of PSTs as a backup measure.

    Just wanted to know if this is feasible.

  • GertjanA's avatar
    GertjanA
    Moderator
    11 years ago

    I would at least prevent adding new PST's and/or prevent adding data to the PST's.

    The goal of a backup in general is IMHO being able to restore. Archiving all PST's into 1 archive does not really allow that.

    If I were in your shoes, I would read up on PST migration. I would do the following:

    Create a GPO that prevents adding items to PST-files, and to create new PST file. Set registrykey to allow EV client to work as expected.

    Configure PST locations, Create a PST Migrator task, configure that.

    Create a new PST policy that has under migration the tick at 'allow pst submission'. Set Create shortcuts at 'this folder under root' = Archived PST file, uncheck 'merge folder structure, uncheck 'restrict shortcuts by age'

    Create a new provisioning group, keep existing policies and settings, except for the PST migration, use the new one. Add some users. run provisioning, sync those users mailboxes. close/open Outlook. a new button will be available in Outlook called PST migrations. The EV-client will find PST's and add those here. They are uploaded to the EV server in parts of 10MB. Verify in Personal Store Management in Console if users start appearing.

    When PST's are showing, apply GPO to those users.

    If you want to allow them to keep using PST files, it is going to be very difficult to keep up with new added data to the PST files.

    It is my opinion that you either import the pst's in the belonging users archive, and stop them from using pst's, or you allow pst's and do nothing with them. A reason for keeping PSt's might be users require access to their old data, then you might be looking at Vault Cache. (local copy of the archive)

    I see you're a partner, you might want to discuss this with your EV SE.

  • sujith_poojari's avatar
    sujith_poojari
    Level 4
    11 years ago

    Thanks for your repy!

    We have already created a policy for disabling PST creation and modification. The problem is migrating these PSTs from user desktop.

    There are users with more than 50 GB of data in their PST files. It would be a painful process to wait for 50+ GB of data to arrive in server in 10MB bits.

    Meanwhile, we have scrapped the mentioned plan and proceed with migrating PSTs into respective Users' archive.

    This is the strategy we are implementing:

    1. Disable PST Creation for User from GPO so that no new data is written in PSTs

    2. Enable client driven PST migration and locate all PST files in their machines

    3. Restore the located PSTs from avamar backup in a temporary folder

    4. Migrate the restored PSTs to Enterprise Vault and delete the PST from the temporary folder

    The drawback would be we have to be careful of what PSTs we archive. Since client driven PST migration marks all the PSTs that are there on the system. There may be users carrying PST data from their previous companies. There is no way of knowing which is the right PST file to migrate unless we actively involve the end user in this process.

     

  • GertjanA's avatar
    GertjanA
    Moderator
    11 years ago

    That sounds ok.

    As for 'data from other companies'. Here (in NL) we consider data that is on our systems as 'our' data. It is a users responsability to make sure no 'external' PST's are there. (in fact it is not allowed).

    That is really tricky subject, but I assume you handle that.

    Thanks for giving the way you do it.

    Can you mark one of the replies as 'solution' please?

  • sujith_poojari's avatar
    sujith_poojari
    Level 4
    11 years ago

    Sure!

    I know it is a tricky spot but this is something unavoidable for an organisation with large number of employers. Going to each and every user to verify pst content would be lengthy but it has to be done since we are aiming to secure every bit of mail content.

    Anyway, thanks a lot for your help!