Category: Microsoft 365 Apps for enterprise

Let’s dig into the details of customizing the M365Apps setup program. I will walk you through a process of discovery but also give you the answers I found at the end.

Gather the Documentation and Tools

Here are the documentation sources and tools we will be using.

• A Windows 11 virtual machine. I am using a Windows PC with Hyper-V installed as the host, but other hypervisors should work too. A virtual machine allows us to experiment. We will make checkpoints so we can keep going back in time to try things repeatedly.
• Office Deployment Tool (ODT). View the documentation here: https://aka.ms/odt. Download the tool from the link near the top of the page.
• Configuration options for the Office Deployment Tool. This documentation is adjacent to the main ODT page. It explains all the parts of an ODT configuration file.
• Office Customization Tool. This is the tool I used in the previous post to quickly generate an ODT configuration file. The tool is here: https://config.office.com/deploymentsettings.
• Sysinternals Suite. Documentation and various downloads are available at https://sysinternals.com/, but I suggest that you install these from the Microsoft Store.

“Microsoft 365 Apps for enterprise” is just the name for the most featureful SKU of Office. I will call it “Office” from now on.

The big picture is as follows:

• Office has a custom installation and update mechanism.
• Its setup.exe file has a fancy name: Office Deployment Tool.
• All installation and update content is hosted by Microsoft in a Content Delivery Network (CDN), referred to below as the “Office CDN”.
• You can download installation/update content locally, install from the Office CDN or a local source, and update from the Office CDN or a local source.

In the narrative below, if it seems like I have missed a step or have glossed over something important, the above documentation should be able to fill in the gaps.

Build the Test Environment

Virtual Machine

Start with a fully-updated Windows 11 virtual machine (VM). Sign in with a local account (preferred) or a Microsoft Account; do not join this VM to Active Directory or Entra ID. Since we will create a checkpoint and repeatedly return to it, we don’t want to download updates and have to reboot to install them over and over again.

• Settings app > Windows Update > Advanced options > Receive updates for other Microsoft products: On
• Settings app > Windows Update > Check for updates
• Microsoft Edge > … > Help and feedback > About Microsoft Edge
• Microsoft Store > Downloads > Check for updates, Update all
• Shut down the VM.
• In Hyper-V Manager, make a checkpoint. I named mine “Updated”.

ODT

1. Power on the VM and sign in.
2. Download the Office Deployment Tool.
3. Right-click > Properties, select “Unblock”, and click OK.
4. Run it to extract Setup.exe.
5. Use the Office Customization Tool to generate an ODT configuration file with nearly everything selected. We’ll use this to build a local download of all the source files so we don’t have to keep re-downloading the content from the Internet every time we retry something. Here is my file, DownloadConfiguration.xml:

   <Configuration ID="GENERATE-YOUR-OWN-GUID">
     <Add OfficeClientEdition="64" Channel="Current" SourcePath="C:\OfficeCDN" MigrateArch="TRUE">
       <Product ID="O365ProPlusRetail">
         <Language ID="en-us" />
       </Product>
       <Product ID="VisioProRetail">
         <Language ID="en-us" />
       </Product>
       <Product ID="ProjectProRetail">
         <Language ID="en-us" />
       </Product>
     </Add>
     <Updates Enabled="TRUE" />
     <RemoveMSI />
     <Display Level="Full" AcceptEULA="TRUE" />
   </Configuration>

6. At an elevated Command Prompt, navigate to the directory where you extracted the ODT.
7. Run setup.exe /? to view the available options. We will use the “/download” switch to stage the content from the Office CDN locally. Did you notice the “SourcePath” attribute in my sample file above? When this configuration file is used with the “/download” switch, the specified path is used as the download destination.
8. setup.exe /download DownloadConfiguration.xml
   When the program exits, check the contents of C:\OfficeCDN to see what was downloaded. Tip: Don’t use the download option on Patch Tuesday like I did. It took nearly an hour!

Sysinternals and Checkpoint

1. Install the Sysinternals Suite from the Microsoft Store.
2. Shut down the VM, and then make another checkpoint named “Staged”. This is our go-back-in-time point for experimentation.

Experiment with a Single App

We will start by experimenting with a single app. This will minimize time spent on installations. We don’t need to install the entire Office suite to observe and understand the mechanics of the installation and first-run experiences.

The first-run experiences are key. Microsoft typically includes several informational messages or choices for users the first time the application runs. As IT professionals building a deployment of these apps with a management system, our job is to minimize such interruptions to our users work. Especially in education and VDI environments (with classrooms and labs), we don’t want users prompted every time they use different PCs.

There are policies available to turn off some first-run experiences, but I am operating under two assumptions here: (1) an app should not need policies layered on just to operate properly and (2) not all of the prompts a user sees can be disabled in a way that leaves the relevant feature usable; that is, sometimes a policy lets you disable a feature to eliminate a prompt, but there is no way to force the feature to be enabled without prompting. Therefore, I am pursuing non-policy-based customizations of the installation process here.

Install Visio

We’ll start with Visio because it is one of the standalone apps in the product family (licensed separately), and so it makes sense to use it if we want to test something alone. Here is the configuration file from above modified to only reference Visio, “InstallVisio.xml”:

<Configuration ID="GENERATE-YOUR-OWN-GUID">
  <Add OfficeClientEdition="64" Channel="Current" SourcePath="C:\OfficeCDN" MigrateArch="TRUE">
    <Product ID="VisioProRetail">
      <Language ID="en-us" />
    </Product>
  </Add>
  <Updates Enabled="TRUE" />
  <RemoveMSI />
  <Display Level="Full" AcceptEULA="TRUE" />
</Configuration>

Run this command from an administrative Command Prompt to install Visio:
setup.exe /configure InstallVisio.xml

Since we’re just testing here, we set the display level to “Full” so we can see what is going on and know when the installation is complete.

Shut down the VM and make another checkpoint named “Visio installed but not run”. This is our go-back-in-time point for first-run-experience testing. Then start the VM again.

Test Visio First-run Experiences

Everything above was preparation for the real work, which starts now.

We will use Sysinternals tools to monitor what happens when we run Visio for the first time—as well as the second time, the third time, and as many times as we need until it stops prompting the user with one-time questions or information.

1. Run Process Monitor elevated. It will immediately start collecting events.
2. Run Visio.
   You will be presented with several pop-up windows. Our goal is to get rid of all of these.
3. Click through the pop-ups, choosing the options to share data whenever those are presented.
   • Sign in to get started with Visio
     Click Skip for now.
   • Create and edit ends soon
     Click the close button (X) in the upper right-hand corner.
   • Microsoft respects your privacy
     Click Next.
   • Getting better together
     Click Send optional data.
4. Close Visio.
5. Switch to Process Monitor and stop collecting events (Ctrl+E).
6. Click Filter menu > Filter… (or press Ctrl+L) to open the Process Monitor Filter dialog window.
7. Set these filters and click OK:
   • Process Name is VISIO.EXE Include
   • Operation is RegSetValue Include
8. Look through the results. On my test VM, that reduced the list of events to 74 (out of tens of thousands) when I ran it in June 2025. When I performed these same steps in August 2025, the filtered list was a much longer 694 events out of nearly 300,000. I found six events of interest:

The word “Common” in the paths of these suggest that the settings apply to all Office apps, not just Visio, so we’ll keep that in mind for later.

• HKCU\Software\Microsoft\Office\16.0\Common\General\ShownFirstRunOptin
• HKCU\Software\Microsoft\Office\Common\ClientTelemetry\SendTelemetry
• HKCU\Software\Microsoft\Office\16.0\Common\Privacy\SendTelemetryTime
• HKCU\Software\Microsoft\Office\16.0\Common\Privacy\SettingsStore\Anonymous\OptionalDiagnosticDataConsentVersion
• HKCU\Software\Microsoft\Office\16.0\Common\Privacy\SettingsStore\Anonymous\ConnectedExperiencesNoticeVersion

9. Run Registry Editor (regedit.exe) and export the registry key containing each of these values to text files. I created three files:
   • ClientTelemetry.reg
   • General.reg
   • Privacy.reg
10. Create a new file in Notepad, VisioFirstRun.reg.
11. Open each of the exported registry files in Notepad, and copy the five values listed above to the VisioFirstRun.reg file. Here is my completed file:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Office\Common\ClientTelemetry]
"SendTelemetry"=dword:00000002

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\General]
"ShownFirstRunOptin"=dword:00000001

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Privacy]
"SendTelemetryTime"="2025-06-11T02:32:56Z"

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Privacy\SettingsStore\Anonymous]
"RequiredDiagnosticDataNoticeVersion"=dword:00000001
"OptionalDiagnosticDataConsentVersion"=dword:00000001
"ConnectedExperiencesNoticeVersion"=dword:00000001

How to reverse that first run without applying a VM checkpoint:

• Delete any Visio or Office-related folders under %APPDATA%\Microsoft and %LOCALAPPDATA%\Microsoft.
• In Registry Editor, delete HKEY_CURRENT_USER\Software\Microsoft\Office.

I ran a second “first run”, and this time, my Process Monitor filter left me with 704 items! I filtered it further to items with “First” in the path and found two more registry values of interest:

• [HKEY_CURRENT_USER\Software\Microsoft\Office\Common\ClientTelemetry]
  “SendTelemetry”=dword:00000002
• [HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\General]
  “FirstRun”=dword:00000000

I added these to my file. Then I made a copy of that file named TryBypassVisioFirstRun.reg. I experimented with removing different registry values from that file, deleting the Office registry under HKCU, applying my file, and then performing a “first run” of Visio until I found the minimal number of registry values needed to stop the first-run prompts:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Privacy\SettingsStore\Anonymous]
"RequiredDiagnosticDataNoticeVersion"=dword:00000001
"OptionalDiagnosticDataConsentVersion"=dword:00000001
"ConnectedExperiencesNoticeVersion"=dword:00000001

[HKEY_CURRENT_USER\Software\Microsoft\Office\Common\ClientTelemetry]
"SendTelemetry"=dword:00000002

With that quick iteration out of the way, it was time to do a real first run of Visio. I copied all the files I had generated out of my VM onto my host PC, and then applied the checkpoint “Visio installed but not run”.

I started the VM and copied my TryBypassVisioFirstRun.reg file to it and then applied it to the registry. No prompts! Perfect!

Is it, though?

Is it perfect, though? Did you notice the word “Anonymous” in several of those registry paths? We didn’t sign into Visio during our testing. Would that path change if the user did sign in, or if Windows were to automatically sign the user in, which is what happens on Entra-joined PCs? Let’s test!

1. Apply the “Visio installed but not run” checkpoint.
2. Start and sign into the VM, and run Visio.
3. In the Sign in to get started with Visio window, click Sign in or create account, and sign in with a licensed account.
4. If you are prompted to Automatically sign in to all desktop apps and websites on this device?,
   • Uncheck Allow my organization to manage my device.
   • Click No, this app only.
5. I got a different window after this. It said Your privacy matters and talked about organizational policies and how I could opt into cloud-backed services by going to File > Account > Account Privacy. Click Close. Perhaps my settings from another installation were brought over and changed my experience.
6. Go to File > Account > Account Privacy heading, and click Manage Settings.
7. Here, there was a “Your privacy matters” window, and “Turn on optional connected experiences” was checked. Did I do that elsewhere for it to be copied here? I would need a clean account to know for sure.

I checked the registry, and sure enough, there is a new key under HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Privacy\SettingsStore with a UUID with a suffix of “_ADAL” for its name. I checked Entra ID, and that UUID is the object ID for my user account. A user-specific setting is not going to help us because we need generic registry value names for the method of replicating per-user settings in the next section. Unfortunately, I’m going to admit defeat here and continue onward with the “Anonymous” values.

Provide Per-user Settings during Installation

Now to make use of those per-user settings we found, we’ll use the AppSettings element of the ODT configuration file. This area of the configuration file writes values into the registry under HKLM\SOFTWARE\Microsoft\Office that are compared, and if not present, are copied, over to the per-user registry the next time an Office app is run by the user. If you are familiar with the Active Setup feature of Windows that runs at user sign-in, this is the same idea—the feature runs at any Office application launch. That means that we can put anything we want here—namely, the handful of registry values we discovered above.

The Office Customization Tool will let you use a nice web app to configure AppSettings in your configuration file, but that tool includes outdated settings that Office no longer uses, and it also only surfaces a subset of known registry values. The settings we need are not included in the tool, so we have to edit the configuration file manually.

Here is the configuration file from before (“InstallVisio.xml”) updated to include these per-user settings that we want copied over for each user and saved as “InstallVisioWithAppSettings.xml”:

<Configuration ID="GENERATE-YOUR-OWN-GUID">
  <Add OfficeClientEdition="64" Channel="Current" SourcePath="C:\OfficeCDN" MigrateArch="TRUE">
    <Product ID="VisioProRetail">
      <Language ID="en-us" />
    </Product>
  </Add>
  <Updates Enabled="TRUE" />
  <RemoveMSI />
  <Display Level="Full" AcceptEULA="TRUE" />
  <AppSettings>
    <User Key="Software\Microsoft\Office\16.0\Common\Privacy\SettingsStore\Anonymous"
          Name="RequiredDiagnosticDataNoticeVersion"
          Value="1"
          Type="REG_DWORD" />
    <User Key="Software\Microsoft\Office\16.0\Common\Privacy\SettingsStore\Anonymous"
          Name="OptionalDiagnosticDataConsentVersion"
          Value="1"
          Type="REG_DWORD" />
    <User Key="Software\Microsoft\Office\16.0\Common\Privacy\SettingsStore\Anonymous"
          Name="ConnectedExperiencesNoticeVersion"
          Value="1"
          Type="REG_DWORD" />
    <User Key="Software\Microsoft\Office\Common\ClientTelemetry"
          Name="SendTelemetry"
          Value="2"
          Type="REG_DWORD" />
  </AppSettings>
</Configuration>

We fill out the required XML elements and leave off the “HKEY_CURRENT_USER” portion of the registry path for each element. Also, DWORD values are written in normal decimal digits. My testing showed that in the “User” element, the “”app” “App” and “Id” attributes shown in the documentation are not required, so they are omitted above.

Revert the test VM to the “Staged” checkpoint and copy the “InstallVisioWithAppSettings.xml” file to the VM.

As before, run this command from an administrative Command Prompt to install Visio:
setup.exe /configure InstallVisioWithAppSettings.xml

Before we run the program, let’s take a look in the registry. If you navigate to “HKLM\SOFTWARE\Microsoft\Office\16.0\User Settings\GUID-FROM-YOUR-CONFIG-FILE\Create”, you should see registry entries for the four settings we configured in the AppSettings element of the configuration file. Here is the export of that key with superfluous lines omitted:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\16.0\User Settings\{51F4E814-F236-4F99-8A1F-06A85D77EDBB}]
"Count"=dword:00000004

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\16.0\User Settings\{51F4E814-F236-4F99-8A1F-06A85D77EDBB}\Create\Software\Microsoft\Office\16.0\Common\Privacy\SettingsStore\Anonymous]
"RequiredDiagnosticDataNoticeVersion"=dword:00000001
"OptionalDiagnosticDataConsentVersion"=dword:00000001
"ConnectedExperiencesNoticeVersion"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\16.0\User Settings\{51F4E814-F236-4F99-8A1F-06A85D77EDBB}\Create\Software\Microsoft\Office\Common\ClientTelemetry]
"SendTelemetry"=dword:00000002

The configuration file GUID is used as a registry key, and underneath it a “Create” key is the root for all the settings that are copied over to HKEY_CURRENT_USER on the next run of any Office app.

Launch Visio, and besides the prompts to sign in, we got what we wanted: No prompts about telemetry, diagnostics data, or connected experiences!

Expand to All Apps

Let’s now expand what we’ve done above to cover all the Office apps. None of the settings we discovered were unique to Visio, so hopefully these will take care of prompts across all Office apps.

Revert the test VM to the “Staged” checkpoint and create new “InstallM365Apps.xml” file on the VM with these contents:

<Configuration ID="GENERATE-YOUR-OWN-GUID">
  <Add OfficeClientEdition="64" Channel="Current" SourcePath="C:\OfficeCDN" MigrateArch="TRUE">
    <Product ID="O365ProPlusRetail">
      <Language ID="en-us" />
      <ExcludeApp ID="Groove" />
      <ExcludeApp ID="Lync" />
      <ExcludeApp ID="OneDrive" />
      <ExcludeApp ID="Teams" />
      <ExcludeApp ID="Bing" />
    </Product>
    <Product ID="VisioProRetail">
      <Language ID="en-us" />
    </Product>
    <Product ID="ProjectProRetail">
      <Language ID="en-us" />
    </Product>
  </Add>
  <Property Name="FORCEAPPSHUTDOWN" Value="TRUE" />
  <Updates Enabled="TRUE" />
  <RemoveMSI />
  <Updates Enabled="TRUE" />
  <RemoveMSI />
  <Display Level="Full" AcceptEULA="TRUE" />
  <AppSettings>
    <Setup Name="Company" Value="YOUR ORGANIZATION NAME GOES HERE" />
    <User Key="Software\Microsoft\Office\16.0\Common\Privacy\SettingsStore\Anonymous"
          Name="RequiredDiagnosticDataNoticeVersion"
          Value="1"
          Type="REG_DWORD" />
    <User Key="Software\Microsoft\Office\16.0\Common\Privacy\SettingsStore\Anonymous"
          Name="OptionalDiagnosticDataConsentVersion"
          Value="1"
          Type="REG_DWORD" />
    <User Key="Software\Microsoft\Office\16.0\Common\Privacy\SettingsStore\Anonymous"
          Name="ConnectedExperiencesNoticeVersion"
          Value="1"
          Type="REG_DWORD" />
    <User Key="Software\Microsoft\Office\Common\ClientTelemetry"
          Name="SendTelemetry"
          Value="2"
          Type="REG_DWORD" />
  </AppSettings>
</Configuration>

Besides the other apps in the suite, I added some extra elements here:

• Several ExcludeApp elements – These prevent component apps from being installed. Each of these is obsolete or redundant. For example, OneDrive and Teams are already preinstalled on Windows 11.
• FORCEAPPSHUTDOWN – Shuts down any running Office apps so the installation can proceed.
• Company – hopefully this is self-explanatory.

As before, run this command from an administrative Command Prompt to install Microsoft 365 Apps for enterprise:
setup.exe /configure InstallM365Apps.xml

Launch each of the apps:

• Visio – works as before; no regressions!
• Project, Access, OneNote, Publisher – no prompts except to sign in
• Word, Excel, PowerPoint, Outlook – these apps won’t actually run without signing in, but they didn’t display any prompts prior to the sign-in prompt
• Outlook (Classic) – Shoot! This one had another prompt. With Process Monitor, I found the likely culprit: “HKCU\Software\Microsoft\Office\16.0\Common\Privacy\SettingsStore\Anonymous\OptionalConnectedExperiencesNoticeVersion”, REG_DWORD, Data = 2. I’ll be sure to add that to the configuration file when I wrap up this series in a later post.

<User Key="Software\Microsoft\Office\16.0\Common\Privacy\SettingsStore\Anonymous"
          Name="OptionalConnectedExperiencesNoticeVersion"
          Value="2"
          Type="REG_DWORD" />

Other than the one extra registry value for Outlook, we should be all set.

Did We Accomplish Our Goals?

Our per-user customizations take care of anonymous users, but users don’t usually remain anonymous in Office because it is licensed per-user. I am aware of three cases:

1. Default installation: A licensed user must sign in for the software to work properly. Office will prompt that user for anything it wants, but the state of the prompts for that user will be synchronized across all instances. When the user signs into another installation of Office, he or she won’t be prompted for the same thing again.
2. Shared PC installation: In this installation mode, a licensed user must sign in for the software to work properly, but none of the user’s licenses are consumed. I have not tested this, but I would expect per-user settings to work exactly the same as with the default installation.
3. Device-based licensing: This installation mode requires the purchase of a device-based license SKU and assignment of the license to the desired devices in Microsoft 365. I have not tested this scenario recently, but my hypothesis is that if the user chooses not to sign into Office, then our anonymous user customizations will be in effect, and if the user does choose to sign into Office, then it will behave the same way as the default installation.

So we may not have accomplished blocking the prompts for any users that sign in, but such users should only ever be shown a given prompt one time, and that is good enough for me.

Coming Up

In future posts, I’ll walk through finalizing the configuration files and building the apps in Intune as well as building the prerequisite apps.

Posts in this series:

1. Deploying Microsoft 365 Apps for enterprise: Overview and Requirements
2. Customizing Setup
3. Building the Application in Intune
4. Building the prerequisite apps.