Video Screencast Help

Pull 'Destination Archive' field from data dump

Created: 17 Dec 2012 • Updated: 18 Dec 2012 | 13 comments
This issue has been solved. See solution.

Hello everyone, I'm newbie today but got a feeling I'll be a regular over the next 6 month. I'm an Exchange Migration Consultant but my current contract has got me doing some EV work as well. Specicifically PST migrations. I've inherrited the lovely task of getting around 10,000 network stored PST files imported into EV. I've been at it for about 3 weeks now and there seems to be problem after problem, after problem. I won't trouble you with them today, I'll do some real forum seaching before I write any posts but before I can get a better picture of our problems I need to see if any of the problems are happening more often on one EV server than the other. Currently we have 2 EV servers doing all the work. My plan is to increase this to 5.

Here's today question!

I can't find a way to export the Destination Archive field from the properties. I just want to know which server the user sits on, currently the Destination Archive field seems to be the only quick way to see this. If theres another field I can get the server from then that would be just as good. If anyone can tell me out to pull this info out of EV I'd be very grateful. I'll can stick it in Excel and do a VLOOKUP afterwards to match it up with my spread sheet so don't worry about it being organised.

Thanks in advance

Comments 13 CommentsJump to latest comment

AndrewB's picture

are you using the pst import wizard? destination archive is just a list of all your mailbox archives from the environment. hopefully this helps:

USE EnterpriseVaultDirectory
SELECT VaultStoreName AS 'Vault Store', ArchiveName AS Archive, DatabaseDSN AS 'Database', SQLServer AS 'SQL Server'
FROM VaultStoreEntry vse, Archive a
WHERE vse.VaultStoreEntryId = a.VaultStoreEntryId
GROUP BY VaultStoreName, ArchiveName, DatabaseDSN, SQLServer

Andy Becker | Authorized Symantec Consultant | Trace3 | Symantec National Partner | www.trace3.com

FunkiPhone's picture

Hi Andrew thanks for your reply,

This is the view I have from the EV Management Console, excuse the crudely done server name hiding. I was trying to pull the Destination Archive field from all the users in that have been discovered and are set to 'Do Not Migrate' before setting them to 'Ready To Copy'. If I right click on the 'Files' container that has all the Do Not Migrate users in and do an export to CSV, it only gives me the following fields

 

File Name, Exchange Mailbox, Status, Size, Migrator, Last Modified

 

AndrewB's picture

let me know if this gets you what you are looking for

use EnterpriseVaultDirectory
select mbxdisplayname as 'Mailbox', ArchiveName as 'Destination Archive', FileSpecification as 'File Name'
from PstFile p, ExchangeMailboxEntry e, Archive a, Root r
where p.ExchangeMailboxEntryId = e.ExchangeMailboxEntryId
and P.VaultId = R.VaultEntryId
and R.RootIdentity = A.RootIdentity
group by FileSpecification, mbxdisplayname, ArchiveName

Andy Becker | Authorized Symantec Consultant | Trace3 | Symantec National Partner | www.trace3.com

FunkiPhone's picture

Hi Andrew,

 

Almost!! The 'mbxdisplayname' and 'ArchiveName' are pulling back the same info. When I open the dbo.Archive table I can see that the ArchiveName column is the same as Exchange display name. I'm looking to get which EV server they are on. I'll go through the tables and see if I can spot anything obvious.  

JesusWept3's picture

It should be something like this 

USE EnterpriseVaultDirectory
SELECT A.ArchiveName "Archive Name"
       P.FileSpecification "PST File",
       R.VaultEntryId "Archive ID",
       VSE.VaultStoreName "Vault Store",
       CE.ComputerName "EV Server"
FROM   PSTFile P,
       Archive A,
       Root R,
       VaultStoreEntry VSE,
       StorageServiceEntry SSE,
       ComputerEntry CE
WHERE  P.VaultId = R.VaultEntryId
  AND  R.RootIdentity = A.RootIdentity
  AND  A.VaultStoreEntryId = VSE.VaultStoreEntryId
  AND  VSE.StorageServiceEntryId = SSE.ServiceEntryId
  AND  SSE.ComputerEntryId = CE.ComputerEntryId
ORDER BY A.ArchiveName, P.FileSpecification
SOLUTION
FunkiPhone's picture

Amazing! Thanks very much. That'll save me hours in the long run. The report the my manager asks for requires me to identify the processing server. I've not had time in the last few weeks to look into a quicker way of doing it rather than manually entering it. Enough if I did have the time, I wouldnt have got anything like your answer, I walked out of my MCSE SQL Module half way!!

GertjanA's picture

Hi funki.

If you are going to extend the number of EV-servers, you might be better of by redistributing the archives first (ie add the 3 new servers, then move archives) before ingesting all the PST's.

Now, seeing you are needing to import 10000 psts, have you considered (or is your client willing to consider) a 3rd party tool? If yes, have a look at PST FlightDeck.

http://www.quadrotech-it.com/products/pst-flightdeck/

It gives you more control than you can with EV. I heard this is really good. In addition, if you need to redistribute lots of archives, look also at QT ArchiveShuttle, TransVault, or BlueSource for moving archives around.

 

Thank you, Gertjan, MCSE, MCITP,MCTS, SCS, STS
Company: www.t2.nl

www.quadrotech-it.com

www.symantec.com/vision

FunkiPhone's picture

Thanks for this info, I'll have a look at PST Flightdesk for the ingesting part, see what they say. Without boring you too much or deviating from my original question we're seeing poor performace from both of the EV server.

Server A is doing pst migrations between 6pm and 6am and is the Temp Store for the pst migrations and its also doing regular mailbox archiving 24hrs a day

Server B is also doing pst migrations from 6pm til 6am and regfular mailbox migrations 24hrs a day.

Server A in particular will sometimes only get through one or two 500Mb pst's in its 12 hour window, sometimes non at all. Server B is slightly better, it will do 15-20 500Mb-1Gb files over a night. I don't have any previous examples to go off but I'd imagine EV should be able to handle a lot more than this each night???

Server A is obviously suffering because its also the temp store for the pst migrations. I'm going to look at moving the temp store on to its own server.

Just out of interest, on a decent spec'd box how many PST's or how many Gb's of data should I be expecting EV to get through each night?

Jeff Shotton's picture

Have a look at the performance guide, which suggests 60000 items/hour of average size 70kb for an 8 core box. Or in other words 4.2GB/hour

http://www.symantec.com/docs/DOC4553

page 34

I've seen more than this...

Regards,

Jeff

Jeff Shotton

Principal Consultant

Adept-tec Ltd

Website: here

FunkiPhone's picture

Thanks Jeff.

I'm woefully short of that then aren't I!! The busier of the 2 servers is only a duel core with 8Gb and the other is duel core with 4Gb. Both are VM's so I'll get the spec bumped up a bit. I'm defintely moving the Temp Storage area onto its own  server as well. I'm not sure we'll ever get to 4.2Gb an hour but I guess its a move in the right direction!

Jeff Shotton's picture

Unfortunately yes. But the question is are you getting poor performance because of configuration, or because the machines are maxed out...

There are also guidelines on implementing EV on VMWare - might be worth a read!

http://www.symantec.com/docs/TECH180094

Regards,

Jeff

Jeff Shotton

Principal Consultant

Adept-tec Ltd

Website: here

FunkiPhone's picture

Thanks again Jeff, I'll give that a read as well. I fear I've inherited a poorly configured setup. Give this doc a read and see if there's any improvements.

Just out of interest. Has anyone had the Email Archiving and PST Archiving roles on the same servers? I'm thinking about splitting them up, 2 servers for Email Archiving and then 2 new servers just for PST archivng and a 5th server for the Temp Store.

Jeff Shotton's picture

Typically they are on the same box, since you need to have the migrator task co-located with the storage service used for the users archives. Dividing this up in a mature environment can be quite painful, and is a primary driver for migration projects where the initial environment was scoped incorrectly and the environment grew too large to cope with on a single server.

It is much easier to consolidate an existing Enterprise Vault environment than it is to scale it out, and since the licensing for EV is not based on the number of EV servers, it makes sense to scale horizontally rather than vertically if you can.

I'm not actually convinced you need the new server for the temp store - just a dedicated disk which is fast enough. The temp store should not consume a lot of server resource.

Regards,

Jeff

Jeff Shotton

Principal Consultant

Adept-tec Ltd

Website: here