Server Drive PST Migration Issue

[ChrisATS]

Environment: Windows Server 2008 R2, EV 10.0.4.1189  Outlook 2007 SP3 w/EV Outlook add-in 10.0.4.1189

Really excited about PST migration improvements in EV10 SP4.  I did a bunch of testing migrating some small PST files located on a DFS network share. Everthing went smoothly and emails were copied to a folder in my Outlook client.  I rolled this out a few weeks ago to all other clients.  I provisioned the same PST Migation policy that I used for testing to the users and I can't get the files to migrate.  I have the PST Locator, PST Collector Task, and PST Migrator tasks running and scheduled to work during business hours.  I've run the provisioning task to enable all the clients.  My initial thought was that the clients were running an older outlook EV add-in.  So I upgraded them to the latest (10.0.4) plugg-in.  Could it be the PST file size?  I tested on files that were only a few Mb.  The files I'm attempting to migrate are 10-12 Gb.  Does the Migrator task have a problem with such large PST files?  When I refresh 'Files' in 'Store Management' it shows "Ready to copy" and does not change.

Thoughts or suggestions are appreciated.

[Rob_Wilcox1]

Failure sure that PSTs on DFS shares won't migrate.  The Directory or Migrator Server processes can't work out 'where' the PST file is really stored, hence can't do anything.

[RahulG]

So are the pst file which are migrating via server driven migration stuck in Ready to copy state or even the client driven migration Pst show the status as Ready to copy ?

Did the migration of Small PSt file went Fine ?

[ChrisATS]

In testing the server driven migration from the DFS worked great.  The user simply needs full access to the file on the DFS.  The feature that I was keen on was the client driven migration which doesn't work from a DFS.  As you decribed that was the exact problem with client driven migration that the locator couldn't find where it was stored.   

[RahulG]

You need to grant the service account elevated rights on the DFS share which holds the PST files.

you may also refer http://www.symantec.com/business/support/index?page=content&id=TECH50673

[ChrisATS]

I tested the server migration under my mailbox and it worked flawlessly.  The service account has full access to the DFS share. 

I saw a post about using EVPM to do the PST migration.  I created a INI file and run EVPM.exe agaist it but nothing happens.  I followed the example in the utilities guide but nothing.  I'm batting 0.000 today!  I see nothing in the event viewer related PST migration tasks.  

[Rob_Wilcox1]

Please post a copy of your INI file that you used, and the parameters you called it with.

[ChrisATS]

Here is the INI file I'm using:

[Directory]

DirectoryComputerName= vs-vault

SiteName = sitename

[Mailbox]

LDAPquery = displayName= chrisze

MailboxDN=/ou=ATS/ou=First Administrative Group/cn=Recipients/cn=chrisze

;

; Default option settings applicable to all PST migrations

;

[PSTdefaults]

PSTLanguage = Western European

ServerComputerName = email.ats-inc.com

MigrationMode = PROCESS

MailboxFolder = Imported Archives

IncludeDeletedItems = true

CancelMbxAutoArchive = true

RetentionCategory = ATS Mailbox Retention

SetPSTHidden = true

SetPSTReadOnly = true

; 

; Individual PST migration settings

;

[PST]

FileName = \\filestore\dfs\users\chrisze\test5.pst

I followed the steps in this TECH67346 to get the MailboxDN.  I've attached a screenshot of the command prompt.

[Rob_Wilcox1 · Accepted solution]

Well...

[Mailbox]

LDAPquery = displayName= chrisze

MailboxDN=/ou=ATS/ou=First Administrative Group/cn=Recipients/cn=chrisze

You can't have both of these defined...Pretty sure with PST migration you want to specify things per PST like the examples here on my blog

http://thingsilearnedtoday.net/2010/10/19/scripted-pst-migration/

[ChrisATS]

Thanks Rob,  Don't know how I didn't stumble upon your blog.  Reading it you didn't use the MailboxDN to specify where to place imported email, you used VaultName instead.  Reading the Utilities guide (10.0.3) I didn't see that as an option, only ArchiveName?

After discovering EVPM I'm going to create a collection of INI files to import my company PST files.  It seems to be the most organized way to accomplish.

[Rob_Wilcox1]

It has been a long time since I tested it or tried it out.. so try either/or those altneratives.. but definitely 'not' the [mailbox] section.

[ChrisATS]

Thanks Rob, that solved that problem.  However, now when I run EVPM I've getting the attached error.  I've restarted the Migrator task in vauld admin console but it still throws the error.  Any ideas?

[Rob_Wilcox1]

There are a few other posts on the forum about 'odd' things happening with PSTs on DFS shares, can you try a different type of share, or try putting the file locally?  Just to verify things are working in the 'simple' mode.

[ChrisATS]

I get the same migration error when the files are moved locally.  I've run the ini file in report mode as your blog suggests to test and I get a good report showing the the PST is ready for migration.  This may be an issue for Symantec.

[Rob_Wilcox1]

You could be right...  maybe double check permissions on the PST file, make sure it is not read-only, and maybe even make sure that you can ingest the PST using the regular Import PST Wizard in the Vault Admin Console.

[ChrisATS]

I used the PST Import wizard and the file has been in "Ready to copy" status for about an hour now.  It has to be a related issue.  The funny thing is that six months ago after I installed SP4 I tested pst migration and all worked well. I can't figure out what changed in that time to break the process.

[Rob_Wilcox1]

That is PST driven migration.. Locate, collect, migrate.

I am suggesting you try the PST import wizard in the VAC.  There are no statuses involved there.

[ChrisATS]

OK, I've never done it that way but I figured it out.  That works great however it imported email that violated my retention policy.  When I did the server driven migration on this test pst file it worked great in that it didn't create shortcuts for email that was older than 1 year which violates the policy.  I specified the proper retention category in the PST wizard but it still created the shortcuts.  I'm assuming that when the mailbox archiving task runs that it will remove these shortcuts. However, I would prefer it not create the shortcuts.  

[ChrisATS]

So I got the server migrations working.  The site settings for the PSTHOLD folder was set to only 10Gb and I was trying to import a 13Gb pst file.  I'm still working with Symantec to try and resolve the EVPM script problems.  

Can you help me interpret the pst log info.  This info comes from a 2Gb pst that I imported.

Migration of PST: \\FILESTORE\G$\users\BRYANFR\archive3.pst

Migration Settings

------------------

Migration Start Time: 12/5/2013 9:50:11 AM

Migration End Time:   12/5/2013 4:05:20 PM

Migration Copy File:  \\VAULT\E$\EVdata\psttemp\Copy3385.pst

Shortcut Mode:        Create shortcuts and move them to Exchange Mailbox

Include Deleted Items:              true

Set PST Hidden:                     true

Set PST Read-Only:                  true

Compact PST:                        false

Delete PST:                         false

Archive Non-Expired Calendar Items: false

Cancel Mailbox Auto-Archive:        true

Merge PST Folders:                  false

Migration Results

-----------------

Number of folders processed: 124

Number of items archived to vault: 50455 of 50575

    - Number of items not eligible for archiving because of PST Migration Policy setting: 120

Number of items moved to mailbox:  120 of 120

    - Number of archived items moved to mailbox: 0

    - Number of other items moved to mailbox: 120

PST Migration completed successfully

   12/5/2013 4:06:10 PM Completed migration of PST: \\FILESTORE\G$\users\BRYAN\archive3.pst

Above it shows 50,455 items archived to vault.  When I go to the users inbox it only shows the 120 that indicated by 'Number of other items moved to mailbox".  If those items aren't eligible for archiving based on policy as indicated above then why are they moved to the mailbox?  Also, where did the 50,455 items go?  My policy states only to import items less than a year old.  I have no problem if all 50,455 are greater than a year old but why doesn't it state something to the affect that they weren't imported?

[Rob_Wilcox1]

To my mind, what you should do is:

a/ Check that the archive contains the right number of items (eg do a search using searcho2k.asp, or search.asp, or look at the vault store usage report)

b/ Sounds like all 50,000 items are >1 year old, therefore shortcuts weren't created (though the items were archived)

c/ When you choose the option to create shortcuts in the mailbox, it's by design that any items that aren't eligible for archiving (based on message class restrictions in the *pst* policy) will be moved to the mailbox at the end of ingestion.

d/ Why doesn't it state it didn't move the 50,000+ items? That's the way the product is right now -- you'd have to file an Idea in the Ideas section of the forum to suggest that really what should happen is that 'something' should say that they were archived but weren't shortcuted into the mailbox.  [It *is* a valid point you raise by the way, I'm just explaining the process]