This is a Part 10 in a series of posts about my experience tackling the migration of PST files.
The first post in the series is here.
The next post in the series is here.
Times Change
Our original goal was to remove all PST files from our user's Home shares and into their Exchange 2010 Archive Mailbox. This has expanded to include all PST files everywhere now. I understand the legal discovery benefit. There is also a Help Desk benefit because users are always calling in about this PST file or that PST file. It's just better not to have PST files at all. So the Powers-That-Be modified our goal to include all PST files no matter where they might be hiding.
The New Challenge
When asked, we were importing PST files for people who were not at HQ as a courtesy. This was limited to a small group of people. While migrating those users, I hit the barrier of bandwidth. Some locations just don't have that much to spare.
Starting off, I just tried to do a conventional OS copy, which didn't work so well. There were several cases where the network team was called in because something "clogging up the WAN and it was very slow."
I tried RoboCopy and posted about using RoboCopy here for pulling the PST files back across the WAN line. Mainly because I knew it had the feature to pause and allow other traffic to move. Seemed like the prefect solution. But there were issues on my end. Like using a conventional OS copy, RoboCopy was always running in the current session of Powershell, or some spawned Powershell session. If you forgot that and exited the session, or logged off the server, the copy stopped.
BITS version
I saw a post on Powershell.com (here) about using BITS transfer and started to investigate. In a few tests BITS performed as advertised. The WAN did not suffer -- the network and server teams had already configured BITS on all PC and servers to operate in a "friendly to the WAN" way. I was just hopping on their bandwagon.
So BITS is my answer for the file transfer. If I rebooted my utility server, the job was still there. If the user rebooted their PC the job was still there.
There are still issues; The PST files are in use nearly all the time, The PC goes to sleep, Users carry their laptop home. Many are all normal problems that can't be scripted. ;)
PST files being "In Use"
We either wait until the user goes home for the day and tell them to shut down Outlook and pray they do. Or we talk them into disconnecting the PST files. If the users want the PST files imported, they usually are very willing to help.
Disconnecting PST files
Users are not to savvy about disconnecting PST files. In many cases we have to help. Usually when we get to this stage, there are many reasons we are helping them. They just don't ever get this kind of experience and don't have a clue. Someone set up PST files for them and they just use them as folders.
PC going to sleep
This requires some hands on. We can send the instructions to the user if they are a local admin on their PC, but many are not. We talk with the Local Technician and ask if they can help us by turning off that feature for a period of time. Or we just log into the machine to do that remotely.
(Will this be my next Powershell script to turn off power save mode and turning it back on, with the PC not having Powershell installed? I should look into that...)
Status Update
This project is moving along smoothly and we've finished almost 50% of the PST on Home Shares. I think I am about done posting about this project, most of what is happening now is just routine. Soon I'll be posting the Module which has all the code. I hope to post that in the next two weeks to a month.
Introduction: The Beginings
Part 1: Script Requirements
Part 2: Add-PSTImportQueue
Part 3: Process-PSTImportQueue
Part 4: Some Tools we added
Part 5: Set-PSTImportQueue
Part 6: About PST Capture
Part 7: More PST Import Tools
Part 8: Using RoboCopy
Part 9: Morning Status Report
Part 10: Using BITS Transfer
Part 11: Get the script / Set up
Part 12: The Functions
