title: Avoid to bring MSI in compatibility mode "Previous version of Windows"
body: <p>I have an installer package for a 32-bit Application (built with MakeMsi, originally for Windows XP, and simplicisticly maintained since then), that fails registering a COM server on modern (64-bit) Windows systems (7, 8, 10). This is what I see when trying to install my MSI normally:</p>
  <p><img src="https://i.stack.imgur.com/KStfG.png" alt="Screenshot of COM registration error" /></p>
  <blockquote>
  <p>Application Error</p>
  <p>Exception EOleSysError in module xyz at 000F0B01. Error accessing the OLE registry.</p>
  </blockquote>
  <p>If I bring the MSI in <strong>compatibility mode <em>Previous version of Windows</em></strong>, the COM server registers successfully. Since <em>&quot;it's working&quot;</em> somehow, I didn't invest much time in exploring the reasons so far. But finally, I'm exhausted to remember our customers (and sometimes also me) again and again of this precondition, so I wish to fix this issue.</p>
  <p>The registration (and de-registration) is done via <em>CustomAction</em>s, as I see looking into it using Orca:</p>
  <pre><code>&quot;[INSTALLDIR.MYAPP]\placeholder.exe&quot; -regserver
  &quot;[INSTALLDIR.MYAPP]\placeholder.exe&quot; -unregserver
  </code></pre>
  <p>For each of those entries, <code>Type</code> is <code>1122</code> and <code>Source</code> is <code>INSTALLDIR.MYAPP</code>.</p>
  <p>I could imagine that the COM server is started with insufficient privileges in the installation procedure, but aren't installers run automatically with administrator rights? I mean, when I (as a standard user) start the installer by double-clicking it, it shows the UAC prompt <em>before</em> the actual installation takes place. Why are the COM servers not run with elevated rights for their registration and de-registration? It's confusing...</p>
  <p><strong>How should I change my MSI to make Windows installer process it successfully?</strong></p>