none
New PST Collection Tool completely and utterly broken

    Frage

  • If this isn't the correct forum for this, please point me in the right direction.

    The new PST Collection Tool used to find and gather PST files throughout an organization so they can be migrated to Office 365 is completely broken. I'm just shocked at how bad this product really is and am beyond belief there is ZERO information posted about it online.

    So, I'm going to start this thread to document my horrific journey trying to use this product. When and if I can work around the bug I will post it here.

    • BUG #1 - In FIND mode, the collection tool is supposed to export a .csv file of all the PSTs files it located. It does not export all the files it found. Instead, it only exports files that are located on File Shares. Any "Machine" locations are left out. This forces you to load the .xml config file to actually see what was discovered.
    • BUG #2 - In COLLECT mode, the tool truncates the CopyLocation specified on the command line when it sends the job to the endpoint. For instance, the tool properly creates the destination folders (so it reads the proper location) and then it sends a job to the endpoint so that the remote endpoint can copy it's PST files to the destination. The JOB definition sent to the endpoint has a truncated path. i.e. I specify for CopyLocation "\\<server>\<sharename>\<path>" and the tool creates a subfolder '\\<server>\<ShareName>\<path>\<DateTime>\<ComputerName>' at the destination and then sends '\\<server>\<ComputerName>\' as the destination in the JOB definition to the endpoint. This causes the copy to fail. For this reason, the tool is utterly broken and completely useless. I've tried several combinations so far to determine what might be the bug, and have not been able to work past this.
    • BUG #3 - More of a documentation error. The documentation says CopyLocation can be "a file server, a network file share, or a hard drive." This is not true. I tried to use a "network file share" located on a NAS and it failed with an "RPC Server Unavailable" message. So, clearly the only "network file share" or "file server" supported is a Windows file server with an open Firewall.
    • BUG #4 - Along the same lines as BUG #2. The collection tool has additional problems with .PST files located on the root of the source computer, at least when it tries to use robocopy. In that instance we get something completely off the wall crazy but it is caused by the collection agent rather than the collection master. In this case we see a source of 'C:\Windows\System32\" \<server>\<computername>\c <pstfile>.pst \is \A-:R \R:3 \w:10\' and a blank destination and blank options sent to RoboCopy.

    To be continued...

    I understand this product was purchased from somebody possibly. Apparently nobody did a single test with it before releasing it.



    • Bearbeitet Appleoddity Mittwoch, 13. September 2017 20:43
    Mittwoch, 13. September 2017 20:26

Alle Antworten

  • It's a free tool, you get what you pay for. It covers some basics, and leaves out a whole lot of other useful features. There are waaaay better products out there, but of course they come at a cost.

    Anyway, let me try and relay this feedback to the PM...

    Donnerstag, 14. September 2017 07:41
  • Hi,

    I've also help to feedback to MS.

    Thanks.


    Regards,

    Jason Chao


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Donnerstag, 14. September 2017 08:45
  • It's a free tool, you get what you pay for. 

    I'm sorry but this is a really poor response, especially from a Microsoft employee.

    First of all, when Microsoft offers software to the general public, we have a basic expectation that the software will be of the kind and quality so to be reasonably assured it is going to work as intended. After all, Windows 10 was FREE to millions of people. I'd love to see how long a Microsoft rep would have a job making a comment about "you get what you pay for," in regards to Windows 10.

    Second, there may be other tools that can be purchased, but Microsoft isn't promoting those tools in their official documentation. Their official documentation suggests using the PST Collection Tool. My organization spends over $100,000 / yr on Office 365 services alone. So let me tell you, it's NOT free!

    Last, this is not a complicated task that requires purchasing some other software to do this. One would think the simple tool Microsoft offered would do the job. But, it truly is completely broken and not usable. I can, and currently am, developing my own Powershell scripting that will accomplish this same task and it will be finished by the end of day. Such a basic task as this should be able be easily handled by a simple tool such as the PST Collection Tool.

    If it's not working, then pull it from general availability. And if the accepted response from Microsoft is that I "get what I pay for" then it has no business being posted online and promoted by Microsoft. No offense, but I don't know of any other way to say you should be ashamed of yourself.


    • Bearbeitet Appleoddity Donnerstag, 14. September 2017 15:05
    Donnerstag, 14. September 2017 14:48
  • You're excused, as I'm not a MS employee, and I can say whatever I want on the subject :) Moreover, I'm participating in these forums and helping others FOR FREE, and I don't feel any shame about it.

    Anyway, as I said above best we can do here is relate your feedback, but that will either result in nothing, or even in the best possible scenario, the issues will get fixed in few weeks, or even months. How does that help you with your current task?

    Thus my suggestion to take a look at third party tools, as sometimes spending few additional $$$ is better than wasting your time and nerves.

    Donnerstag, 14. September 2017 18:53
  • Can you please share that powershell script with the rest of us if there is no legal binding to it.?
    Mittwoch, 4. Oktober 2017 22:47
  • Can you please share that powershell script with the rest of us if there is no legal binding to it.?

    I've been debating what to do with it.

    It's still in development. What I wanted to be simple ended up turning in to something that turned quite sophisticated.

    I now have the tool reliably finding all the PSTs in my organization for the past week or so, and literally today we are starting production runs of "Collecting," because it seems to be bug free. I still need to add a couple more features, which would be "remove" and the exporting of a CSV file compatible with Office 365 import.

    It's looking like I'm going to have to extend the volume shadow copy ability to network file shares somehow too. But, I've debated just running those as separate collection jobs on each local server that holds PST files. The workstation collection is the hard part because of the unpredictability of the endpoint.

    Anyways, I wouldn't say it's safe or ready to share yet, but it's definitely going to get the job done. I'm not sure how useful that will be to others, because it is designed to support our environment, not everybody's environment. Limit of Windows 7 or newer, all systems have to be on a domain, etc. 

    I'll be glad when this is over... Ugh... The hell of it all. :) PST files are evil.

    Donnerstag, 5. Oktober 2017 14:32
  • No problemo, I understand. luckily my environment is all windows 10, few win 7 ( end devices that is ) and domain joined ( server 2012 r2 ). I'm about ready to hit this entire network with a good old

    c:\>remove-item " \\FILESERVER\UNC\* " -include .pst -recurse

    and call it a day... Lol jk

    Any help is good help, and greatly appreciated. I can decipher pretty well.

    Donnerstag, 5. Oktober 2017 17:53
  • This also appears to not be listing PST files connected to Outlook. The documentation says it does, but it doesn't seem to be. Do I have to specify what path to look for PST files that might be "connected" to Outlook?

    The whole point of me looking for connected PST files is to find in-use/Connected PST files regardless of where they are (local, share, etc.).  As it is, this utility is useless, because I can already to a generic search for *.PST across the network without downloading a tool. That doesn't give me anything useful.

    I need to not only find PSTs, but I need to find the ones *connected* to Outlook.  The rest of them out there are old backups and other junk I don't need. As it is, this tool, as far as I can tell, is just an overly complex way to search for *.PST on a network.  Anyway, the documentation says "Note that the tool can find and get information about PST files that are open in Outlook and PST files that are connected to Outlook profiles."   Doesn't seem to.





    Montag, 23. Oktober 2017 20:24
  • Would you be willing to share your script, even a rough development, im literally sick of looking at these PSTs and just want this project over....pleaseeee help......
    Mittwoch, 25. Oktober 2017 16:14
  • This project turned out to be more than I expected.

    I do have working scripts to do what I need. Some of it is meant to meet my needs, rather than the general public. But, I believe it should work ok for others.

    I'm new to trying to post sourcecode online and I will try to see if I can get something up online for others to use within the next day or two.

    Mittwoch, 25. Oktober 2017 16:26
  • This also appears to not be listing PST files connected to Outlook. The documentation says it does, but it doesn't seem to be. 

    I never got the impression that it would do this.

    Neither will my scripts.

    Based on my experience, you'd be better off just doing a basic test of the product, rather than worrying about these fine of details. Unless something has changed, there is NO chance of this actually working for you - so it would be a shame to waste time trying to figure out how to find "active" PST files to figure out nothing else works either.

    Mittwoch, 25. Oktober 2017 16:29
  • Any update on this? I, too, have found out the hard way in the middle of a huge project that I'm lead on that the PST Collection Tool should be removed from all websites and Bill Gates himself should issue a formal apology for every slapping Microsoft's name on it.

    I'm curious if you ever got your script "production ready" and put it out there somewhere? I simply don't have the time to work up my own script at this point.

    Mittwoch, 14. Februar 2018 13:54
  • Any update on this? I, too, have found out the hard way in the middle of a huge project that I'm lead on that the PST Collection Tool should be removed from all websites and Bill Gates himself should issue a formal apology for every slapping Microsoft's name on it.

    I'm curious if you ever got your script "production ready" and put it out there somewhere? I simply don't have the time to work up my own script at this point.

    Yes, I completed the script for my purposes and successfully imported 2TB in 800 PST files and removed all the PST files from our organization.

    I uploaded the code and tried to create a readme to follow to get you started. My organization won't support me putting business time in to developing or supporting this. So, I'll do what I can, when I can.

    https://github.com/appleoddity/PSTCollector

    Mittwoch, 14. Februar 2018 15:56
  • In assisting a client with previously no mail retention control, I was authorized to implement a hard enforcement. Being that the compliance policy was of high priority, consisting of NO pst use allowed on the network AT ALL. This allowed me to deploy a seek and destroy of all PSTs to include those that were either hidden, attached to outlook, or in the recycle bin. Users with PSTs loaded to their outlook session will get an error stating the archive could not be found. This is due to the "Destroy" instruction within the script. It is a brave solution with no reverting possible and should not be considered lightly. All users should be informed plenty in advance and reminded consistently.

    Mittwoch, 14. Februar 2018 16:51
  • In assisting a client with previously no mail retention control, I was authorized to implement a hard enforcement. Being that the compliance policy was of high priority, consisting of NO pst use allowed on the network AT ALL. This allowed me to deploy a seek and destroy of all PSTs to include those that were either hidden, attached to outlook, or in the recycle bin. Users with PSTs loaded to their outlook session will get an error stating the archive could not be found. This is due to the "Destroy" instruction within the script. It is a brave solution with no reverting possible and should not be considered lightly. All users should be informed plenty in advance and reminded consistently.

    If you look at the code I provided, there is a script for automating the removal of PST files from the Outlook configuration. If you deploy GPOs to prevent the creation of new PSTs, and prevent the growth of existing PSTs, users can clean up their PSTs and move data out of them. You can then run the script I provided, and it will remove the PSTs from Outlook and prevent users from adding them back in. After that you can gracefully delete them.
    Mittwoch, 14. Februar 2018 16:54
  • I have done some testing and have exactly the same issues with CSV not being created and PST's not being copied.  I did notice that shares you documented in Bug #2 DO actually get created while the tool is running (i.e. \\server\computername) but Robocopy fails - looks like a permissions issue.  If I time it just right and manually create the share it does copy PST's over successfully.

    Is there an update on this Microsoft?  What are our support options?


    Donnerstag, 12. April 2018 13:23
  • Hi,

    Why don't you try the best alternative of PST collection tool, if tool is not working properly.

    Regards,
    Bruce

    Donnerstag, 26. Juli 2018 13:15