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 seems to be a swarm of legacy programs like RichProfile out there that worked on previous versions like 2000/2003 on XP, 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. You know what I care about more than cosmetics? Ultimate functionality. Even if I save only 5 minutes of my time on the phone dealing with a user request to configure mail in XenApp, I’m calling this project a huge success even though it took me hours to develop ;D

First things first. You will need PowerShell v2.0 on the server where the script will be executing. You can find this out by running this variable and looking at the Major column.


Ok next step is to create a new GPO or use an existing one that is applied to your Citrix or TS server and enable Group Policy loopback processing.


To 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.

Then 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 GPOs are processed after the user’s GPOs, they have precedence if any of the settings conflict.

After that, 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

Page generated in 5.2492 seconds.
Advertisment ad adsense adlogger