Fixed: Outlook 2010 creating “BACKUP OF” profiles for roaming users

During the development of our Windows 7 image with Office 2010, we began seeing a problem around our users’ Outlook 2010 profiles on the pre-production builds. On occasion, after logging into a machine for the first time, our users would be prompted to choose an Outlook profile upon the first launch of Outlook. Every time the Choose Profile dialog box was presented, it had only a single option in the profile name menu, and that option was always “BACKUP OF Outlook”, where Outlook was our customized profile as configured in a .PRF and applied via the Office OCT.


We were not using .PST files and we were not using Windows Roaming Profiles, but we were using Group Policy logon and logoff scripts to roam certain portions of our user profiles, including the entire registry key at [HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles]. With 20/20 hindsight, it’s clear that this unwanted behavior was not happening when we logged into a machine for the first time as a brand-new user (ie, while also preventing the logon script from merging the Profiles key from another machine into HKCU before Outlook was opened), but before a pattern had emerged, we considered the problem to be intermittent.

We were building machines using System Center 2012 Configuration Manager and using the Microsoft Office Customization Tool for configuring our .MSP and .PRF files. We were familiar with Active Setup and recognized that Outlook was doing a similar first-run process to set up a profile for what it thought was a new user. When it discovered that an Outlook profile already existed, it created a new profile named “BACKUP OF Outlook” and offered the user a Choose Profile dialog box with this profile as the only choice, presumably because “BACKUP OF Outlook” was not yet set to be the default profile.

Observed symptoms

When the logon script had roamed a user profile from another machine by importing the Profiles key, and before Outlook was launched for the first time, our Profiles key looked similar to this (the snippet has had the juicy bits removed):

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles]

[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook]

After Outlook had been launched and the Choose Profile dialog box had been presented, the registry looked similar to this:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\DeletedProfiles]

[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\DeletedProfiles\Outlook]

[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles]

[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook]

[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\BACKUP OF Outlook]

The changes we noted were that a new profile named BACKUP OF Outlook had been created, a new DeletedProfiles key had been created, our desired profile had been flagged for deletion via a subkey under DeletedProfiles, and the DefaultProfile string value under the Profiles key that had been pointing to our profile had been deleted.

If we launched Outlook but cancelled out of the Choose Profile dialog box, closed Outlook, and put the Profiles key back to the state before Outlook was launched, we could then relaunch Outlook without issue. It had no objection to using the roamed profile on the second launch or any subsequent launches. The problem might arise if this user roamed the Profile key to yet another machine, but we had not yet identified a pattern or means of reproducing the problem.

Complicating factors

This was happening during a time of rapid development, when the Office OCT was being changed frequently, and machines were hitting the floor with different Office builds. The users logging into these machines were not always aware of all of the changes between builds, and in many cases we were not roaming the user’s profile in an attempt to get a ‘clean’ test of the new build. These factors contributed to the difficulty in establishing a pattern or recognizing commonalities.

A decent amount of time was spent researching problems with Outlook profiles in general, and this research turned up a few forum threads ( that indicated the problem stemmed from the .PRF file. (We also found some mentions of an “undocumented” property named BackupProfile in the .PRF: and We experimented briefly with making changes to the .PRF as hinted at in these threads, but felt that such trial-and-error experimentation was not the best use of our time.

The epiphany

A tip passed along by one of our Kraft Kennedy consultants lead to the break-through.

When 32-bit Office is installed with an .MSP generated by the OCT, a GUID-named key is created under [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\14.0\User Settings] that contains a value named Count with a data of 1. For example:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\14.0\User Settings\{75BB133B-F5DD-423C-8321-3BD0B50322A5}]

Much like Active Setup, when Outlook launches, it looks for a corresponding key in [HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\User Settings], also with a
value named Count with a data of 1. If the matching key is not found, Outlook does its first-run process, applies the .PRF, and then writes the GUID-named key to HKCU so that the first-run behavior doesn’t happen on that machine again.

In our case, each time we made a change to the OCT and cooked up a new OSD image in SCCM, the GUID-named key under HKLM changed. When a user from an old machine roamed to one of these new machines (or when a user initially on a new machine roamed to an older one), the GUID-named keys did not match and the first-run behavior fired off.

The resolution

Now that we better understood what was happening, we could evaluate a few ways to handle the situation. One way was to detect whether the user already had a default profile, and then add the current machine’s HKLM GUID key to her HKCU. Another way was to try to get a better handle on the .PRF and configure it to not create the backup, even when the first-run behavior was triggered. The latter seemed preferable, because we weren’t sure that avoiding the first-run behavior entirely was desirable. We suspected that there might be an advantage to allowing Office’s first-run process to play out, for example, if future changes to the OCT were made that needed to be added to the user’s environment.

After some communication with Microsoft, we made two changes to our .PRF that suppressed the creation of the BACKUP OF profile. The first change was to add BackupProfile=False to the Section 1, General area. The second change was to use UniqueService=Yes in the Section 4, Service1 area.

The corrected .PRF, in part, looks like this:

;Automatically generated PRF file from the Microsoft Office Customization and Installation Wizard

; **************************************************************
; Section 1 - Profile Defaults
; **************************************************************



; Section 4 - Default values for each service.


Some final thoughts

I would note that we are using BackupProfile=False, while many of the forum threads on the subject (incorrectly?) reference the property value as No, as in BackupProfile=No.

This “undocumented” BackupProfile property is actually quite well-documented, and even highlighted as important, in the TechNet article at

A TechNet blog post from August, 2010, at is dedicated to a problem with multiple Exchange accounts that is resolved by making the same two changes to the .PRF. The blog post helpfully points out that the manually edited .PRF file must exist in the same location as the .PRF originally used with the OCT:

NOTE: If Outlook/Exchange settings in the MSP file need to be edited in the future, the custom PRF file created to work around this issue must be copied to the same location as it was when originally imported into the OCT (i.e., C:\Custom14.PRF) on the machine that you’re running the Office Customization Tool on when modifying the MSP file.

The work yet to be done

Without further testing, it remains unclear whether the BackupProfile=False instruction, possibly in combination with other options in the .PRF, causes settings in the .PRF to be merged into the existing Outlook profile, or whether the presence of an existing profile means Outlook just doesn’t do anything with the .PRF.

Customize Outlook profiles by using an Outlook Profile (PRF) file
An existing profile can be either overwritten or updated when a new .prf file is executed. Several settings control how the new settings are applied:

The OverwriteProfile setting can be set to Yes, Append, or No. To update existing profiles, set the value to Append. This preserves the existing profile and updates the sections that have been changed. To overwrite existing profiles with a new profile, set the value to Yes. To prevent overwriting an existing profile, set the value to No.

The ModifyDefaultProfileIfPresent setting can be set to True or False. When set to True, Outlook will modify the default profile even if the new and existing profile names are different.

I would also like to better understand how the GUID-named key gets its name. The TechNet article on the Office Customization Tool in Office 2010 seems to possibly allude to the GUID being a timestamp.

Every time that you save a customization file in the OCT, the tool updates the customization file’s sequencing number with the current computer date and time stamp and generates a new update globally unique identifier (GUID).

As it seems to be the subject of some debate, I want to point out that Microsoft supports applying Setup customization .msp files to existing installations of Office 2010. I suspect, but have not attempted to confirm, that this would generate additional GUID-named keys.

7 thoughts on “Fixed: Outlook 2010 creating “BACKUP OF” profiles for roaming users

  1. Chris Mitchell

    Oliver Baty is the only one on the Internet who figured this out. THANKS. Our image automaticall sets up Outlook. I was bypassing this and setting it up thyrough the control panel. Outlook upon next startup, does what it was supposed to do and sets up a profile. When one already exists it names the new profile BACKUP OF %profilename% and puts the user into it. Let Outlook create the profile and when it has, I can delete it and setup my own. Once it has done it, it doesn’t do it again, so no more backup copies. Fixed.

  2. evlilik hazırlıkları

    When one already exists it names the new profile BACKUP OF %profilename% and puts the user into it. Let Outlook create the profile and when it has, I can delete it and setup my own. Once it has done it, it doesn’t do it again, so no more backup copies. Fixed.

  3. Mark Bosch

    I too am experiencing this problem. I found your site which is very helpful in tracking down the issue. but i also came across these 2 pages that also could be possible problems. In my case we had the problem on xenapp servers.


    maybe it could help other if they stumble on to this page 🙂

  4. Andrew Koch

    I just wanted to say, Thank You!! I had been experiencing this issue with Office 2010 and even 2013. I have been doing multiple test deploys in a Hyper-V VM and tried different settings and that stupid BACKUP of Outlook kept coming back. I would then restore a previous snapshot, make some changes in OCT, and redeploy, and again it kept coming back. This finally resolved the issue.

    And to shed some light, Microsoft states: “There is a known issue in which an additional Exchange account is added to the Outlook profile when a user who already has an exchange account in the profile is upgraded from Outlook 2003 or Outlook 2007.”
    I was experiencing this issue even upgrading from Outlook 2010 to 2013, but the profile was originally a 2007 one that got migrated to 2010, so that could still be why it was happening. At any rate I am no longer plagued by this issue and can now confidently roll out the deployment.

  5. Daryl Yamamoto

    Thank you for the informative post.

    Originally, I had been looking at the FirstRun reg key after the value had changed due to either the msp file applied or Office repair.

    We utilize a XenDesktop streamed system with roaming profiles. After reverting FirstRun back to the original value failed to make a difference, I came across the Windows Messaging Subsystem key including the “BACKUP OF” profiles.

    The msp was set to create a new Outlook profile each time. A new PRF has been generated with the fixes from this post.

    Thanks again for stopping my head banging any further.

  6. Charles Hurst

    Thanks for this very informative and detailed analysis of the problem.

    I’ve been struggling with this recently although I did have another symptom in which the default outlook profile (non backup of version) woulds till the be default to load however it refused to send emails due to send as permissions not working. Hopefully if I edit the PRF and stop the backup of profile being created I will also stop the corruption on the main profile too!

    Thanks again.

  7. Jeremy Saunders

    This is a really nice write up Oliver! It’s been a problem for as long as I can remember and has been a challenge to manage for those of us that deploy “Citrix” solutions. I wrote a script several years ago that runs after the Office install that makes the First-Run value the same across all servers/workstations. This avoids the problem altogether.

    It would be nice if Microsoft added this intelligence into their Customisation Wizard,


Leave a Reply

Your email address will not be published. Required fields are marked *