Mitigating Spectre variant 2 with Retpoline on Windows

Updated May 14, 2019:  We're happy to announce that today we've updated Retpoline cloud configuration to enable it for all supported devices!* In addition, with the May 14 Patch Tuesday update, we've removed the dependence on cloud configuration such that even those customers who may not be receiving cloud configuration updates can experience Retpoline performance gains. 

*Note: Retpoline is enabled by default on devices running Windows 10, version 1809 and Windows Server 2019 or newer and which meet the following conditions:

• Spectre, Variant 2 (CVE-2017-5715) mitigation is enabled.
  • For Client SKUs, Spectre Variant 2 mitigation is enabled by default
  • For Server SKUs, Spectre Variant 2 mitigation is disabled by default. To realize the benefits of Retpoline, IT Admins can enable it on servers following this guidance.
• Supported microcode/firmware updates are applied to the machine.

Updated March 1, 2019:  The post below outlines the performance benefits of using Retpoline against the Spectre variant 2 (CVE-2017-5715) attack—as observed with 64-bit Windows Insider Preview Builds 18272 and later. While Retpoline is currently disabled by default on production Windows 10 client devices, we have backported the OS modifications needed to support Retpoline so that it can be used with Windows 10, version 1809 and have those modifications in the March 1, 2019 update (KB4482887).

Over the coming months, we will enable Retpoline as part of phased rollout via cloud configuration. Due to the complexity of the implementation and changes involved, we are only enabling Retpoline performance benefits for Windows 10, version 1809 and later releases.

Updated March 5, 2019:   While the phased rollout is in progress, customers who would like to manually enable Retpoline on their machines can do so with the following registry configuration updates:

On Client SKUs:

1. reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 0x400
2. reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 0x400
3. Reboot

On Server SKUs:

1. reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 0x400
2. reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 0x401
3. Reboot

Note: The above registry configurations are for customers running with default mitigation settings. In particular, for Server SKUs, these settings will enable Spectre variant 2 mitigations (which are enabled by default on Client SKUs). If it's desirable to enable additional security mitigations on top of Retpoline, then the feature settings values for those features need to be bitwise OR'd into FeatureSettingsOverride and FeatureSettingsOverrideMask.

Example: Feature settings values for enabling SSBD (speculative store bypass) system wide:
FeatureSettingsOverride = 0x8 and FeatureSettingsOverrideMask = 0
To add Retpoline, feature settings value for Retpoline (0x400) should be bitwise OR'd:
FeatureSettingsOverride = 0x408 and FeatureSettings OverrideMask = 0x400

Get-SpeculationControlSettings PowerShell cmdlet can be used to verify Retpoline status. Here’s an example output showing Retpoline and import optimization enabled:

Speculation control settings for CVE-2017-5715 [branch target injection] 
 
Hardware support for branch target injection mitigation is present: True  
Windows OS support for branch target injection mitigation is present: True 
Windows OS support for branch target injection mitigation is enabled: True 
… 
BTIKernelRetpolineEnabled           : True 
BTIKernelImportOptimizationEnabled  : True 
...

Since Retpoline is a performance optimization for Spectre Variant 2, it requires that hardware and OS support for branch target injection to be present and enabled. Skylake and later generations of Intel processors are not compatible with Retpoline, so only Import Optimization will be enabled on these processors.

---

In January 2018, Microsoft released an advisory and security updates related to a newly discovered class of hardware vulnerabilities involving speculative execution side channels (known as Spectre and Meltdown) that affect AMD, ARM, and Intel CPUs to varying degrees. If you haven’t had a chance to learn about these issues, we recommend watching The Case of Spectre and Meltdown by the team at TU Graz from BlueHat Israel, reading the blog post by Jann Horn (@tehjh) of Google Project Zero.

We have also had multiple posts detailing the internals of our implementation to handle these side-channel attacks.

1. Mitigating speculative execution side channel hardware vulnerabilities
2. KVA Shadow: Mitigating Meltdown on Windows
3. Analysis and mitigation of L1 Terminal Fault (L1TF)

For today’s post, we have kernel developers Andrea Allievi and Chris Kleynhans describing our design and implementation of retpoline for Windowswhich improves performance of Spectre variant 2 mitigations (CVE-2017-5715) to noise-level for most scenarios. These improvements are available today in Windows Insider Builds (builds 18272 or newer, x64-only).

Introduction

At a high level, the Spectre variant 2 attack exploits indirect branches to steal secrets located in higher privilege contexts (e.g. kernel-mode vs user-mode). Indirect branches are instructions where the target of the branch is not contained in the instruction itself, such as when the destination address is stored in a CPU register.

Describing the full Spectre attack is outside the scope of this article. Details are in the links above or in this whitepaper from Intel.

Our original mitigations for Spectre variant 2 made use of new capabilities exposed by CPU microcode updates to restrict indirect branch speculation when executing within kernel mode (IBRS and IBPB). While this was an effective mitigation from a security standpoint, it resulted in a larger performance degradation than we’d like on certain processors and workloads.

For this reason, starting in early 2018, we investigated alternatives and found promise in an approach developed by Google called retpoline. A full description of retpoline can be found here, but in short, retpoline works by replacing all indirect call or jumps in kernel-mode binaries with an indirect branch sequence that has safe speculation behavior.

This sequence, shown below in Figure 1, effects a safe control transfer to the target address by performing a function call, modifying the return address and then returning.

RP0:  call RP2                 ; push address of RP1 onto the stack and jump to RP2
RP1:  int 3                    ; breakpoint to capture speculation
RP2:  mov [rsp], <Jump Target> ; overwrite return address on the stack to desired target
RP3:  ret                      ; return

While this construct is not as fast as a regular indirect call or jump, it has the side effect of preventing the processor from unsafe speculative execution. This proves to be much faster than running all of kernel mode code with branch speculation restricted (IBRS set to 1). However, this construct is only safe to use on processors where the RET instruction does not speculate based on the contents of the indirect branch predictor. Those processors are all AMD processors as well as Intel processors codenamed Broadwell and earlier according to Intel’s whitepaper. Retpoline is not applicable to Skylake and later processors from Intel.

Windows requirements for Retpoline

Traditionally the transformation of indirect calls and jumps into retpolines is performed when a binary is built by the compiler. However, there are several functional requirements in Windows that make a purely compile-time implementation insufficient.

These key requirements are:

1. Single binary: Windows releases are long-lived and must support a wide variety of hardware with a single set of binaries. On some hardware retpoline is not a complete mitigation because of alternate behavior of the ret instruction and retpoline must not be used. Further, future hardware may eliminate the need for retpoline entirely. Therefore, a Windows implementation of retpoline must allow the feature to be enabled and disabled at boot time using a single set of binaries, based on whether the underlying hardware is vulnerable, compatible and whether Spectre variant 2 mitigations are enabled on the system. Further, the runtime overhead of retpoline support should be minimal when the feature is disabled.
2. 3rd party device drivers: A lot of the code that runs in kernel mode is not part of Windows and consists of 3rd party device driver code. Traditional retpoline would only be secure if all these drivers were recompiled with a new version of the compiler. Given the breadth of Windows 3rd party driver ecosystem, it is not realistic to expect all non-inbox 3rd party drivers to be recompiled and released to customers at the same time. Therefore, a Windows implementation of retpoline must be able to support a mixed environment, providing high performance when running drivers that have been updated, but allowing for graceful fallback to hardware-based mitigations upon entering a non-retpoline driver to preserve security.
3. Driver portability: Windows drivers are not bound to a specific release of Windows, many drivers that are built today for Windows 10 will also support older versions of the operating system. Therefore, a Windows implementation of retpoline must ensure that drivers compiled with retpoline support can run on a version of Windows that does not support retpoline.

General Architecture

To satisfy requirement 1 and 3, we decided that binaries would ship in a non-retpolined state and then be transformed into a retpolined state by rewriting the code sequences for all indirect calls. This ensures that systems that do not use retpoline can use the binaries as compiled without needing any support for retpoline and with minimal runtime cost.

However, performing the transformation at runtime does lead to one problem. How do we know what transformations need to be applied? Disassembling and analyzing driver machine code to locate all indirect calls is not practical.

Dynamic Value Relocation Table (DVRT)

To solve this problem, we collaborated with the compiler team in Visual Studio to develop a system whereby the compiler can emit a new type of metadata into driver binaries describing each indirect call or jump in the system. This metadata takes the form of new relocation entries in the Dynamic Value Relocation Table (DVRT).

The DVRT was originally introduced back in the Windows 10 Creators Update to improve kernel address space layout randomization (KASLR). It allowed the memory manager’s page frame number (PFN) database and page table self-map to be assigned dynamic addresses at runtime. The DVRT is stored directly in the binary and contains a series of relocation entries for each symbol (i.e. address) that is to be relocated. The relocation entries are themselves arranged in a hierarchical fashion grouped first by symbol and then by containing page to allow for a compact description of all locations in the binary that reference a relocatable symbol.

At build time, the compiler keeps track of all references to these special symbols and fills out the DVRT. Then at runtime the kernel will parse the DVRT and update each symbol reference with the correct dynamically assigned address. Importantly, the kernel will skip over any DVRT entries it does not recognize (i.e. those with an unknown symbol) so adding new symbols to the DVRT does not break older versions of Windows.

These properties meant the DVRT was a perfect place to store our retpoline metadata, however the existing DVRT format needed to be extended to support retpoline.

Based on Windows requirements, we classified indirect calls/jumps into three distinct forms and each of these forms has its own type of retpoline relocation and corresponding runtime fixup.

1. Import calls/jumps
2. Switchtable jumps
3. Generic indirect calls/jumps

Let’s talk a little about each of these types of calls.

Import Calls/Jumps

Import calls/jumps are, as the name implies, used for calls/jumps made by a binary to functions that have been imported from another binary. When compiling with retpoline, the compiler ensures that all such calls conform to the following form:

48 FF 15 XX XX XX XX     call qword ptr [_imp_<function>]
0F 1F 44 00 00           nop

The call or jmp instruction always directly references the import address table (IAT) and has 5 bytes of additional padding (to be used by the retpoline fixup).

Switchtable Jumps

Switchtable jumps are used for jumps made to other locations within the same function and are so-named because of their usage in implementing C/C++ switch statements. When compiling with retpoline support the compiler ensures that such calls are always made through a register and take the following form:

FF D0                    jmp rax
CC CC CC                 int 3

Generic Indirect Calls/Jumps

All other indirect calls/jumps fall into the generic type. To simplify the retpoline relocation format and the corresponding fixup logic, the compiler ensures that all such indirect calls/jumps provide their target address in the RAX register. The exact format of the call/jump instruction however differs depending on whether it is protected by control flow guard (CFG).

Loading binaries at runtime

Now that we have a way to identify all the indirect calls/jumps in the binary, we need to apply the fixups.

The NT memory manager has long had infrastructure to apply fixups to binaries at runtime. This infrastructure was extended to understand retpoline relocations and their corresponding fixups.

But what exactly do these fixups look like? As mentioned earlier, the Windows implementation needs to support mixed environments in which some drivers are not compiled with retpoline support. This means that we cannot simply replace every indirect call with a retpoline sequence like the example shown in the introduction. We need to ensure that the kernel gets the opportunity to inspect the target of the call or jump so that it can apply appropriate mitigations if the target does not support retpoline.

For this reason, we transform every indirect call or jump into a direct call or jump to a kernel provided “retpoline stub function”. For example, an indirect call to an imported function that looks like this:

call qword ptr [_imp_ExAllocatePoolWithTag]     ; Target address located at a REL32 offset
nop                                             ; Padding

Will be replaced at runtime with a direct call to the retpoline import stub:

mov r10, qword ptr [_imp_ExAllocatePoolWithTag] ; R10 = target address
call _guard_retpoline_import_r10                ; Direct REL32 call to the stub function

There are several retpoline stub functions each of which is specialized to the type of call/jump it handles. However, each function generally performs the following steps:

1. Check if the target binary supports retpoline
• Prior to transferring control to the target address, the function must determine whether the target address belongs to a driver that supports retpoline. To determine this, the kernel maintains a sparse bitmap of the entire kernel-mode address space with each bit describing a 64 KB region of the address space. Bits in this bitmap are set to 1 if and only if their corresponding region of address space belongs to a kernel-mode binary that fully supports retpoline.
• If the bitmap check determines that the target address does not belong to a retpolined binary, the stub function has to fall back to the hardware-based Spectre variant 2 mitigation (by setting IBRS to restrict branch speculation) and then perform a regular indirect call/jmp. Otherwise, the kernel does not need to set IBRS. On processors that do not support IBRS, retpoline will, instead, perform IBPB if user-to-kernel protection is enabled as described here.
• Since the target of a switch table jump is always in the same binary as the source (and therefore the target is guaranteed to support retpoline), this bitmap check is omitted from the switchtable jump stub functions.
2. Check if the target address is a valid CFG target
• For CFG instrumented indirect calls/jumps the retpoline stub function is responsible for checking the kernel-mode CFG bitmap to verify that the target address given is a valid CFG call target. If this check fails, then the stub function will bugcheck the system to prevent any exploit that attempts an indirect control transfer to an invalid address.
3. Transfer control to the target using a retpoline.

The usage of these stub functions ensures that we can satisfy the requirement to support mixed environments, however they do introduce one additional problem. The x64 direct call/jump instruction can only encode a target address within 2 GB of the call-site (since the target is specified by a signed 16- or 32-bit offset). Since the retpoline stub functions are implemented in the NT kernel binary this would generally mean that drivers would have to be loaded within 2 GB of the kernel binary.

To work around this requirement, all retpoline stub functions are contained within a single section of the NT kernel binary and have been carefully written to take no dependencies on their position relative to the rest of the binary. This allows us to map the physical memory pages backing the retpoline stub functions immediately after every driver in the system, giving each driver its own “copy” of the retpoline stub functions that is guaranteed to be within 2 GBof every indirect call/jump.

Import optimization

Indirect calls due to imported functions are by far the most common form of indirect control transfers in kernel-mode. The import call targets are determined at driver load time by processing the import address table (IAT) and remain constant throughout the driver’s lifetime. This means that most of the work provided by the retpoline import stub is unnecessary because we know at driver load time exactly where each of these calls will end up going and we know whether the target binary supports retpoline or not. Hence, we can use a much faster calling sequence.

With import optimization, we use the retpoline fixup infrastructure to replace eligible import calls with direct calls to the imported function. This eliminates the overhead of the retpoline import call stub as well as the guaranteed branch prediction miss due to retpoline itself. To be eligible for import optimization, a call must meet the following requirements:

1. The call/jump must be from a retpolined binary to another retpolined binary.
• This is necessary to maintain the security guarantees of retpoline because once we’ve rewritten the indirect call into a direct call the kernel no longer gets a chance to observe the target address and enable IBRS.
2. The target of the call must be within 2 GB of the call site.
• This is because as mentioned above direct call/jump instructions on x64 can only encode a 32-bit offset.
• In order to virtually guarantee that import optimization can be applied all retpolined modules, the OS loader and kernel make sure that all kernel-mode modules are packed tightly in the address space while maintaining address space layout randomizations (ASLR).

Here is an example of how the code generation for the call is modified.

Original code sequence

call [__imp_<Function>]                   ; Call to an imported function
nop                                       ; 5-byte nop

Import Optimized code sequence

mov r10, [__imp_<Function>]               ; R10 = target address (normal transformation)
call <Function>                           ; Direct REL32 call to target

Import optimization turned out to be a big performance win! Hence, even on processors where retpoline cannot be used due to alternate return instruction behavior, we still use import optimization.

Conclusion

Retpoline has significantly improved the performance of the Spectre variant 2 mitigations on Windows. When all relevant kernel-mode binaries are compiled with retpoline, we’ve measured ~25% speedup in Office app launch times and up to 1.5-2x improved throughput in the Diskspd (storage) and NTttcp(networking) benchmarks on Broadwell CPUs in our lab. It is enabled by default in the latest Windows Client Insider Fast builds (for builds 18272 and higher on machines exposing compatible speculation control capabilities) and is targeted to ship with 19H1.

To check if retpoline and import optimizations are enabled, you can use the PowerShell cmdlet Get-SpeculationControlSettings. You can also use NtQuerySystemInformation to programmatically query retpoline status.

For a more in-depth look, here is a talk by Andrea Allievi at BlueHat 2018 talking about retpoline on Windows.

Give the latest builds a try and let us know your experience!

Examples of Revit Installation Commands

When installing the software from the command line, refer to these examples.

The following examples use these placeholder values:

• <Serial-Prefix>: first 3 digits of the serial number
• <Serial-Postfix>: last 8 digits of the serial number
• <License-Server>: name of your local network license server
• <Product-Key>: product key for the software

Note: The following example commands are word-wrapped to increase legibility. When using these commands, place them on a single line.

Trial mode

setup.exe /t /qb /w /language en-us /c RCL: INSTALLDIR="%PROGRAMFILES%\Autodesk" 
CP_PREFERENCE=RVT-en-US-i CP_SELECTED="RVT-en-US-i;RVT-en-US-m"

setup.exe /t /qb /w /language en-us /c RVT: INSTALLDIR="%PROGRAMFILES%\Autodesk" 
ADLM_EULA_COUNTRY=US INSTALLLEVEL=5

Stand-alone license

setup.exe /t /qb /w /language en-us /c RCL: INSTALLDIR="%PROGRAMFILES%\Autodesk" 
CP_PREFERENCE=RVT-en-US-i CP_SELECTED="RVT-en-US-i;RVT-en-US-m"

setup.exe /t /qb /language en-us /c RVT: INSTALLDIR="%PROGRAMFILES%\Autodesk" 
ACADSERIALPREFIX=<Serial-Prefix> ACADSERIALNUMBER=<Serial-Postfix> ADLM_PRODKEY=<Product-Key> 
ADLM_EULA_COUNTRY=US INSTALLLEVEL=5

Single network license

setup.exe /t /qb /w /language en-us /c RCL: INSTALLDIR="%PROGRAMFILES%\Autodesk" 
CP_PREFERENCE=RVT-en-US-i CP_SELECTED="RVT-en-US-i;RVT-en-US-m"

setup.exe /t /qb /language en-us /c RVT: INSTALLDIR="%PROGRAMFILES%\Autodesk" 
ACADSERIALPREFIX=<Serial-Prefix> ACADSERIALNUMBER=<Serial-Postfix> ADLM_PRODKEY=<Product-Key> 
ADLM_EULA_COUNTRY=US INSTALLLEVEL=5 ACADSTANDALONENETWORKTYPE="3" 
ACADLICENSESERVERTYPE="Single Server License" ACADLICENSETYPE="Network License" 
ACADSERVERPATH="<License-Server> 000000000000"

Distributed network license

setup.exe /t /qb /w /language en-us /c RCL: INSTALLDIR="%PROGRAMFILES%\Autodesk" 
CP_PREFERENCE=RVT-en-US-i CP_SELECTED="RVT-en-US-i;RVT-en-US-m"

setup.exe /t /qb /language en-us /c RVT: INSTALLDIR="%PROGRAMFILES%\Autodesk" 
ACADSERIALPREFIX=<SerialPrefix> ACADSERIALNUMBER=<SerialPostfix> ADLM_PRODKEY=<Product-Key> 
ADLM_EULA_COUNTRY=US INSTALLLEVEL=5 ACADSTANDALONENETWORKTYPE="3" 
ACADLICENSESERVERTYPE="Distributed Server License" ACADLICENSETYPE="Network License" 
ACADSERVERPATH="@<License-Server1>;@<License-Server2>;@<License-Server3>;"

Redundant network license

setup.exe /t /qb /w /language en-us /c RCL: INSTALLDIR="%PROGRAMFILES%\Autodesk" 
CP_PREFERENCE=RVT-en-US-i CP_SELECTED="RVT-en-US-i;RVT-en-US-m"

setup.exe /t /qb /language en-us /c RVT: INSTALLDIR="%PROGRAMFILES%\Autodesk" 
ACADSERIALPREFIX=<Serial-Prefix> ACADSERIALNUMBER=<Serial-Postfix> 
ADLM_PRODKEY=<Product-Key> ADLM_EULA_COUNTRY=US INSTALLLEVEL=5 ACADSTANDALONENETWORKTYPE="3" 
ACADLICENSESERVERTYPE="Redundant Server License" ACADLICENSETYPE="Network License" 
ACADSERVERPATH="@<License-Server1> 000000000000 27005;@<License-Server2> 000000000000 27005;
@<License-Server3> 000000000000 27005;"

Parent topic: Install Revit from the Command Line

Related Reference

• Options and Parameters for the Revit Installation Command Line

REF: https://knowledge.autodesk.com/support/revit-products/troubleshooting/caas/CloudHelp/cloudhelp/2017/ENU/Revit-Installation/files/GUID-299A5C2A-775F-47BF-A69C-1C9F1393CCC5-htm.html

Install Revit from the Command Line

Products and versions covered 

By: 

Help

Apr 21 2017

Instead of using the Autodesk installer, you can install the software from the command line.

To prepare for the installation

• If you are using network licensing, ensure that license servers are set up and operating correctly. See Workflow: Planning, Installing, and Configuring Network Licenses.
• Prepare the target computer:
  • Follow the guidelines in About Installation Prerequisites.
  • Apply relevant service packs to the operating system.
  • Disable anti-virus software.
  Note: You do not need to download and install language packs for Revit. Instead, the software provides built-in support for all supported languages. After installation, you can start the software in another language by launching a desktop shortcut.

To prepare the installation commands

• Setup.ini contains 2 important sections:
  • [RVT] describes the installation of the Revit software.
  • [RCL] describes the installation of Revit content libraries.
  When using setup.exe to install from the command line, use the /c option to call each of these sections individually so you can pass relevant parameters for each part of the installation.
• First install the content libraries; then install the software.
  This order ensures that Revit.ini contains the correct paths to all content files, including templates. If you install the software before the content, when launching the software you will encounter an error about missing template files.
• When installing the content libraries, pass the CP_SELECTED parameter to specify the content packs to install, and the CP_PREFERENCE parameter to specify which content pack is the default. See Select Content for a Revit Installation.
• For a list of available content packs, go to <installer location>/Content/Revit/<language>, and locate the XML files that start with RVT (for Revit) or RLT (for Revit LT). When specifying the content packs to install (with the CP_SELECTED and CP_PREFERENCE parameters), use these XML file names without the XML file extension as parameter values.
  Note: To generate and save a list of these content pack XML files in your home folder, use the following command:
  

  dir /b R??-??-??-?/xml > %userprofile%\filelist.txt

• The basic structure of the command-line options and parameters for a typical installation is as follows:

  setup.exe <all other options> /c <ini section name>: <parameter> <parameter> <...>

  See the examples.

Topics in this section

• Options and Parameters for the Revit Installation Command Line
  When performing a stand-alone installation of Revit from the command line, you can use options and parameters with the installation command.
• Examples of Revit Installation Commands
  When installing the software from the command line, refer to these examples.

Parent topic: Revit Installation and Configuration

Related Concepts

• Select Content for a Revit Installation
• About Languages for Revit

Related Tasks

• Install Revit on a Single Computer
• Customize a Stand-Alone Revit Installation
• Install Revit Add-Ins

REF: https://knowledge.autodesk.com/support/revit-products/troubleshooting/caas/CloudHelp/cloudhelp/2017/ENU/Revit-Installation/files/GUID-12F5DE6D-4C0E-4945-A92E-889C5D8A78F3-htm.html

Deploy Outlook mail profile settings via GPO or script

When an end-user starts Outlook for the first time in a managed environment, he or she usually expects that Outlook is fully configured already and simply opens to the Inbox. Being a good administrator, you obviously want to create this experience for your users as well.

AutoDiscover in Exchange 2007 and later together with Auto Account Setup (or AutoConfigure) in Outlook 2007 and later alleviates some of this pain already by presenting the user with dialogs for which they only have to click Next and Finish or prompt them to supply commonly known information such as their email address and password. Outlook then figures out the technical configuration itself and has the user quickly up and running.

As this still requires end-user interaction, which could lead to confusion or errors, you can take this a step further by deploying Outlook mail profile settings. The Office installation offers various options for this.

• Deploy Office with a customization file (msp-file)
• Deploy a msp-file if Office is already installed
• Deploy a prf-file via a (Group Policy) logon script

---

Deploy Office with a customization file (msp-file)

Directly deploying Outlook mail profile settings when deploying Office is the best way to go. By using the Office Customization Tool (OCT) you can prepare your deployment and specify default settings for your users including Outlook mail profile settings.

Download: Office 2007 Office Customization Tool (OCT)
Download: Office 2010 Office Customization Tool (OCT)
Download: Office 2013 Office Customization Tool (OCT)

Installing and running the OCT

To be able to use the OCT you must do the following;

1. Execute the downloaded OCT for your version to extract it to a convenient location.
2. Copy the contents of your Office 2007/2010/2013 installation media to the deployment location.
3. Copy the Admin folder from the extracted OCT location to the installation directory of your Office deployment folder.
   • If your installation DVD contains both the 32-bit and the 64-bit version of Office 2010 or Office 2013, you’ll have to copy it to the x86 or x64 folder, respectively.
4. Start setup.exe from the deployment location with the /admin switch;
   setup.exe /admin

Note:
The OCT works for any Office Suite. Be aware of the fact though that the Home and Student version doesn’t contain Outlook.

The mail profile can be configured in the Outlook section of the OCT.
(click on image to enlarge)

Deploying Office with the msp-file

Once you’ve configured all the settings that you want, use File-> Save As… to save the msp-file to the Updates folder of your Office deployment folder. When Office is being installed, it will automatically apply the msp-file and configure the settings for the user.

For further customizations required to deploy Office 2010 or Office 2013 via a GPO see;
Deploy Office 2013 by using Group Policy computer startup scripts

Bug:Outlook 2010 SP1 introduced a bug which affects the function of importing a prf-file when it contains settings for an Exchange account. To properly process the prf-file, you must set the OverwriteExisitingService value in Section 4 of the prf-file to Yes (open the prf-file in Notepad to make the changes);
OverwriteExisitingService=Yes

This OverwriteExistingService setting applies to Section 6 and Section 7 of the prf-file and not to any already configured mail profile or mail account which are controlled by the OverwriteProfile and ModifyDefaultProfileIfPresent options in Section 1.

To apply this customization when creating an msp-file, export the prf-file, make the customization and then set the OCT setting to Apply PRF and point it to the modified prf-file.

Without this modification, Outlook will ignore the configuration specified in the prf-file and start the “Microsoft Outlook 2010 Startup Wizard” as usual.

This issue has been first fixed in hotfix KB2584053 and is also included in later updates.

Deploy a msp-file if Office is already installed

If Outlook 2007, Outlook 2010 or Outlook 2013 is already installed on the client computers, you can create a new msp-file via the OCT which only holds mail profile settings and nothing else. You can then deploy this msp-file.

This deployment can be done via Microsoft System Center Configuration Manager or via a different deployment application within your organization.

If you want to do this via a Group Policy, you’ll have to do it via a startup script as the installation requires Administrator level rights. Since users usually don’t have installation rights, a logon script will fail. The command to use in your startup script would be similar to;

msiexec.exe /p "\\server\share\custom.msp"

Outlook 2003
If you are still using Outlook 2003, then you can use the Office Resource Kit (ORK) to create a Custom Maintenance Wizard File (cmw-file). To apply this to your users, deploy the Maintwiz.exe file to the Office directory of the user’s machine and execute it with a the location of the cmw-file as the parameter in a GPO startup script.

"C:\Program Files\Microsoft Office\Office\Maintwiz.exe" "\\server\share\custom.cmw"

Deploy a prf-file via a (Group Policy) logon script

The OCT or ORK also allows you to export the Outlook mail profile as a prf-file. This prf-file can then be distributed to your users via a logon script. As logon scripts work on user instead of computer level, it will allow you to more easily deploy different mail profiles to different sets (Organizational Units) of users. Outlook offers 2 built-in mechanisms for this.

/importprf startup switch

One method is to import prf-files via the /importprf command line switch. The downside of this command line is that it will also directly launch Outlook and will execute at each logon and could therefore possibly also modify end-user alterations to the mail profile.

ImportPRF Registry value

The ImportPRF Registry value has the benefit that it can be set without needing to open Outlook. The first time that Outlook is launched, Outlook will look at this value and if it is set, it will use the specified prf-file to configure Outlook.

Key: HKEY_CURRENT_USER\Software\Microsoft\Office\<version>\Outlook\Setup
Value name: ImportPRF
Value type: REG_SZ
Value: path to prf-file

For this Registry value to work, the FirstRun and First-Run value may not exist in the Setup key.

Deployment script

While setting the key for the fist time isn’t hard to do, once the FirstRun or First-Run values have been set, updating the mail profile without ending up applying it each time the user logs on is a bit more complicated. To prevent this, you can use the vbs-script below which has the following characteristics.

• Checks if the profile already exists. If it does, it won’t import the prf-file again.
• Allows for setting a version for your prf-file. By increasing the version in the script, you can force the (updated) prf-file to be reapplied again.
• It doesn’t start Outlook.
• Can be used as a (Group Policy) logon script.
• Works at user-level rights.
• Works for all versions of Outlook.

Download: deployprf.zip

The following code is contained in the zip-file download. You can use the code below for review or manual creation of a vbs-script.

'==================================================== ' Description: This script determines if a specified mail profile already exists. ' If it doesn't, it will set the path to the prf-file containing ' the mail profile configuration settings. ' ' author : Robert Sparnaaij ' version: 2.0 ' website: http://www.howto-outlook.com/howto/deployprf.htm '==================================================== '=====BEGIN EDITING===== 'Name of mail profile as in the prf-file ProfileName = "Outlook" 'Path to the prf-file ProfilePath = "\\server\share\profile.prf" 'Increase the ProfileVersion whenever you want to reapply the prf-file ProfileVersion = 1 '======STOP EDITING UNLESS YOU KNOW WHAT YOU ARE DOING===== const HKEY_CURRENT_USER = &H80000001 const HKEY_LOCAL_MACHINE = &H80000002 strComputer = "." Set objRegistry = GetObject("winmgmts:\\" & _ strComputer & "\root\default:StdRegProv") 'Determine path to outlook.exe strKeyOutlookAppPath = "SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\OUTLOOK.EXE" strOutlookPath = "Path" objRegistry.GetStringValue _ HKEY_LOCAL_MACHINE,strKeyOutlookAppPath,strOutlookPath,strOutlookPathValue 'Verify that the outlook.exe exist and get version information Set objFSO = CreateObject("Scripting.FileSystemObject") If objFSO.FileExists(strOutlookPathValue & "outlook.exe") Then strOutlookVersionNumber = objFSO.GetFileVersion(strOutlookPathValue & "outlook.exe") strOutlookVersion = Left(strOutlookVersionNumber, inStr(strOutlookVersionNumber, ".0") - 1) Else Wscript.Echo "The location of OUTLOOK.EXE couldn not be verified." & vbNewLine & _ "Please contact your system administrator." WScript.Quit End If 'Set profile Registry path based on Outlook version If strOutlookVersion >= 15 Then strKeyProfilePath = _ "HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\" & strOutlookVersion & ".0\Outlook\Profiles\" _ & ProfileName & "\9375CFF0413111d3B88A00104B2A6676" Else strKeyProfilePath = _ "Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\" _ & ProfileName & "\9375CFF0413111d3B88A00104B2A6676" End If 'Check if a mail profile already exists strLastChangeVer = "LastChangeVer" objRegistry.GetBinaryValue _ HKEY_CURRENT_USER,strKeyProfilePath,strLastChangeVer,strValueLastChangeVer 'Check if the prf-file needs to be reapplied If ProfileVersion > 1 Then strKeyProfileVersionPath = "SOFTWARE\HowTo-Outlook\DeployPRF" strProfileVersionName = ProfileName objRegistry.GetDWORDValue _ HKEY_CURRENT_USER,strKeyProfileVersionPath,strProfileVersionName,strValueProfileVersion If IsNull(strValueProfileVersion) OR ProfileVersion > strValueProfileVersion Then ReapplyPrf = True End If End If 'Apply the prf-file if needed If IsNull(strValueLastChangeVer) OR ReapplyPrf Then 'The mail profile doesn't exist yet so we'll set the the ImportPRF key and remove the FirstRun keys 'Verify that the configured prf-file exist Set objFSO = CreateObject("Scripting.FileSystemObject") If objFSO.FileExists(ProfilePath) Then 'Create the Setup key, set the ImportPRF value and delete the First-Run values. strKeyOutlookSetupPath = "SOFTWARE\Microsoft\Office\" & strOutlookVersion & ".0\Outlook\Setup" strImportPRFValueName = "ImportPRF" strImportPRFValue = ProfilePath objRegistry.CreateKey HKEY_CURRENT_USER,strKeyOutlookSetupPath objRegistry.SetStringValue HKEY_CURRENT_USER,_ strKeyOutlookSetupPath,strImportPRFValueName,strImportPRFValue strFirstRunValueName = "FirstRun" objRegistry.DeleteValue HKEY_CURRENT_USER,_ strKeyOutlookSetupPath,strFirstRunValueName strFirstRun2ValueName = "First-Run" objRegistry.DeleteValue HKEY_CURRENT_USER,_ strKeyOutlookSetupPath,strFirstRun2ValueName 'Save the applied ProfileVersion if larger than 1. If ProfileVersion > 1 Then objRegistry.CreateKey HKEY_CURRENT_USER,strKeyProfileVersionPath objRegistry.SetDWORDValue HKEY_CURRENT_USER,_ strKeyProfileVersionPath,strProfileVersionName,ProfileVersion End If Else Wscript.Echo "Crucial file in script could not be found." & vbNewLine & _ "Please contact your system administrator." End If Else 'The mail profile already exists so there is no need to launch Outlook with the profile switch. 'Of course you are free to do something else here with the knowledge that the mail profile exists. End If 'Cleaup Set objRegistry = Nothing Set objFSO = Nothing
Click in the area above and press CTR+A to select all. Press CTRL+C to copy the code.

ref: https://www.howto-outlook.com/howto/deployprf.htm