Auto Create Outlook MAPI User Profiles Group Policy PowerShell Script

I could not for the life of me find a single script, function or group policy setting that would auto create the Outlook 2007 and 2010 MAPI user profile for my internal users. Perhaps my scenario is different than most. My situation was a XenApp server which both external clients and internal employee’s connect to for published apps. I didn’t want to add a logon script to my internal user’s GPO because it would run on their local machines and inside of the ICA session, and I didn’t want to run a computer level script because it would run for external clients too. That only meant one thing: I would actually have to develop something myself T.T

There is a swarm of legacy programs like RichProfile out there that works on legacy versions such as Outlook 2000 & 2003 on WinXP, but come on…this is 2013, the year of coffee at 6pm while trying to quit your decade-long cigarette habit. My approach is a witches brew of PowerShell v2.0+, Active Directory Security Groups, Group Policy Loopback Processing, Office Customization Tool, delirium and sloppy programming. If only 5 minutes of my time are saved on the phone dealing with a user’s request to configure email in XenApp, the project is a success though it took me hours to develop ;D

You will need PowerShell v2.0+ on the server where the script will be executing. You can find version info by running a built-in environment variable and looking at the Major column.

$PSVersionTable.PSVersion or $Host.version

Next step is create a new GPO or use an existing which is applied to your Citrix or TS server and enable Group Policy loopback processing.

Enable Loopback processing Mode

Using Group Policy Management Console, edit the GPO you desire, expand Computer Configuration\Policies\Administrative Templates\System\Group Policy,
and then double-click User Group Policy Loopback Processing Mode.

Select the appropriate option (Replace or Merge).

NOTE: In case of conflict in Merge Mode, the users policies from this GPO has precedence. Because the computer’s GPO are processed after the user’s GPO, they have precedence if any of the settings conflict.

Add the following user level login script setting to the GPO

 # Travis Runyard 3.26.2013
 # Auto-create Outlook MAPI Profiles for Citrix and TS environments
 # Requires PowerShell v2.0+
$memberOf = ([ADSISEARCHER]"samaccountname=$($env:USERNAME)").Findone().Properties.memberof -replace '^CN=([^,]+).+$','$1'
 $group1 = "YourActiveDirectorySecurityGroupName1"
 $group2 = "YourActiveDirectorySecurityGroupName2"
 if(($memberOf -contains $group1) -or ($memberOf -contains $group2))
 $path = "HKCU:\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook"
 If(-not(Test-Path -Path $path))
 Start-Process "C:\Program Files (x86)\Microsoft Office\Office12\Outlook.exe" -ArgumentList "/importprf c:\scripts$\Outlook2007mapi.prf" -WindowStyle Minimized
 Start-Sleep -s 5
 Get-Process outlook | % { $_.CloseMainWindow() }
 #If that did not close Outlook then kill it
 Stop-Process -ProcessName Outlook -Force

Change the $group1 and $group2 variables to your Active Directory security group names which your target users are a member of. If you’re running Outlook 2010 instead of 2007 like I am here, change the folder path Office12 to Office14. Obviously change the path to your prf file in the argument. As you can see what this script will do is checks if the user is a member of either security groups, checks if a profile already exists in the registry, and if not exists, runs Outlook.exe while minimized with the /importprf switch which imports your custom settings that you created earlier, sleeps for 5 seconds, then attempts to gracefully close the Outlook.exe process which is like clicking the X button, and if that fails it forcefully kills the process. Killing Outlook doesn’t prevent the profile creation. Lulz to you Outlook.exe.

This will accomplish all of my requirements:
1.) Automatically create internal user’s MAPI profile for Outlook 2007 and 2010 in a XenApp environment without any user interaction
2.) Does not run on internal employee’s local user workstations
3.) Does not run for external users connecting to the same XenApp server
4.) Internal users can send email directly from applications like Adobe Reader or Foxit without having to load Outlook first
5.) Able to go home tonight knowing that you’ve developed something unique and have a few beers without feeling guilty

Tags: GPO
Disqus Comments Loading...
All Rights ReservedRegular Version