I need a PS script to remotely copy local PST files to network and remotely reconfigure Outlook to use the PST on the network

In our environment we want to store users' Outlook PST files on the network because we do not backup the local workstations. We know there are some workstations where Outlook is using local PSTs. I got a Powershell script to find local Outlook PST files in EE question Q_28533359. This found many workstations with local PSTs. Now I am hoping it is possible to use a Powershell script to remotely copy these to the network home directory for the user and to configure Outlook to use the PST file on the network instead of on the local workstation. I realize this may require running the script locally with the user whose PST we want to move logged on but if it is possible to do remotely without the user logged on that would be preferable. If this is only possible with VB script I would accept that but would prefer Powershell.
donanderAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

QlemoBatchelor, Developer and EE Topic AdvisorCommented:
You are aware that you should never use a PST stored on network?
0
donanderAuthor Commented:
Yes I am aware that is what Microsoft says but we do not backup our workstations so this is our only recourse. We have been storing and using PSTs on network drives since I came to work at this company in 1998 and have never had any problems related to storing them on the network.
0
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
Then you were very lucky. Many folks will tell you that regular PST repairs are required ...

IMHO the best approach is to use a login script to perform the change. Otherwise you would have to load the user profile, or mount the user hive, to perform changes.

Edit: Above assumes you insist on having network share PSTs. The common way to handle the backup issue is to perform a backup prior to starting Outlook, and keeping PSTs local.
0
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

QlemoBatchelor, Developer and EE Topic AdvisorCommented:
The VBS in http://community.spiceworks.com/scripts/show/2320-update-pst-path-registry looks promising, and I'm hesitant to convert that to PS, as I'm not fully clear about how it works.
The script mails to Help Desk, but if you replace that by a copy command you should be fine (use FileSystemObject for performing the copy / move).
0
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
Here is the converted and simplified PS counterpart, currently in test mode (= changing nothing - see comments for what to change for getting the real experience). Still it processes the current, local user profile only.
cls
# *** change this to your destination root
$UNCLocation = "\\server\pstshare\$env:UserName\"
dir -Recurse 'HKCU:Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook' |
  ? { $_.Property -contains "001f6700" } |
  % {
    get-itemproperty $_.PsPath "001f6700"
  } |
  % {
    $bytes = $_."001f6700"
    $curpath = (-join [Char[]] $(foreach ($i in 1..($bytes.Count-1)) { if ($i % 2) { $bytes[$i]*256 + $bytes[$i-1] } })).Trim(0)
    if ($curpath -like "?:*") {
      Write-Host "Local path found in $($_.PsPath.Replace($_.PsProvider.ToString()+'::','')): $curpath"
      Move-Item $curpath $UNCLocation -whatif   # *** Remove -whatif if certain
      if ($?) {
        $newpath = Join-Path $UNCLocation (split-path -Leaf $curpath)
        # *** replace "001f6700 test" with "001f6700" if certain
        Set-ItemProperty $_.PsPath "001f6700 test" -value ([Byte[]]($(foreach ($i in ([byte[]] [Char[]] $newpath)) { $i, 0 })+@(0,0)))
      }
    }
  }

Open in new window

0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
donanderAuthor Commented:
Sorry about the delay in responding. I will test this early next week.
Thanks,
Don
0
footechCommented:
Just thought I would contribute something as recently I've been looking at the ways (where I could find them) that strings are stored as byte arrays, hex representations, etc. in registry values and other places.

You could replace line 11 with
$curpath = [text.encoding]::Unicode.GetString($bytes)

Open in new window

and also line 18 with
Set-ItemProperty $_.PsPath "001f6700 test" -value ([text.encoding]::Unicode.GetBytes($newpath))

Open in new window

I noticed in line 18 of Qlemo's code that it adds a couple of zeros at the end of the byte array.  When comparing to an existing registry entry, these appear to be extra and unneeded.  The [text.encoding]::Unicode.GetBytes($newpath) bit doesn't create those extra zeros.
0
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
footech,
Using Text.Encoding class is a good idea (and thanks for bringing that in). However, those registry values for paths are ending with an U0000 (hex 00 00), which needs to get removed when using as pathname, and added back for registry values. The appended zeroes are not unneeded.
So line 11 needs to be
$curpath = [text.encoding]::Unicode.GetString($bytes).Trim(0)

Open in new window

and line 18
Set-ItemProperty $_.PsPath "001f6700 test" -value ([text.encoding]::Unicode.GetBytes($newpath+[char]0))

Open in new window

0
footechCommented:
You are correct.
I took a second look at why I didn't think they were necessary and saw that I had re-used a variable I shouldn't have, so when I tested it looked like there was an extra set of "00 00" at the end.  My mistake and thanks for the correction.
Don't you just love dealing with invisible characters in strings?
0
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
Oh yes, they are great. Garbled output, strange concatenation, length mismatches, …
0
donanderAuthor Commented:
Thanks!
Don
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Powershell

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.