Solution: Corrupt Registry Fix for Mimecast for Outlook Client Deployment

Document created by user.W911BlF2XxVQ on Jun 17, 2016Last modified by user.W911BlF2XxVQ on Jun 28, 2017
Version 6Show Document
  • View in full screen mode

IMPORTANT:  This is a solution created by a Mimecast customer and is offered "as-is". It is not official Mimecast guidance. The article contains information about editing the Windows registry. Editing the registry incorrectly can damage the applications and operating system on your computer. Before attempting, you should make a backup of the system, including system-state.  Mimecast is unable to accept responsibility for any issues arising form editing the registry.


Updated 19/06/16




I don't work for either Mimecast or Microsoft, but I want to present a solution that worked for me for a problem involving the Mimecast for Outlook client and Microsoft's Group Policy.


Recently I ran into quite a problem (for me anyway) when making a test deployment for Mimecast for Outlook 32-bit version 6.3 with Active Directory Group Policy. Following the issue, I could not install version 6.3, even manually, on my test PC. When trying to install manually, with administrative rights, the installer threw the following error and halted;


Only per machine installation is allowed. Please make sure the user has appropriate rights to do so.


I could still install 6.2 on the machine just fine, but even installing and uninstalling this, then retrying, gave the same result. If this sounds familiar, hopefully this solution will help you.


Please further bear in mind that this could be a very big problem if I had deployed this incorrect policy to a whole domain.




Primary DC - Windows Server 2012 R2

Secondary DCs - Windows Server 2008 R2 (One at another site)

Client PCs - Windows 7 Pro 64-bit, mostly standard Dell desktops, including the one affected, some laptops (Some Windows 10Pro x64 tablets)

Office - Office 365 32-bit (still as the Office 2013 variant at this stage for Exchange compatibility)

Exchange 2007 single server - We are kind of in process of moving to Office 365 but the actual migration hasn't started just yet.

Mimecast for front end spam filtering and for archiving.

Just over 100 users.




The source of the problem was me frankly. But hey, so was the solution!

Recently I created a test deployment for Mimecast for Outlook using Group Policy Software Deployment. Unfortunately I didn't pay enough attention to the documentation that says that Mimecast for Outlook must be deployed per computer and I was going to test it just with a few of our Administrators, starting with myself. So I went per user...

If you try to deploy Mimecast for Outlook per user, you will probably have registry settings written that will block future attempts to install the same client version. In my case, I eventually decided that a per computer strategy was better either way, because I don't want Mimecast installing on any of our servers (except the Terminal Server). So I changed the policy to per-computer.

At this point the client was still not installing. Re-reading the documentation, (Installing Mimecast for Outlook using Group Policy) I now understood why it wouldn't initially. It can't be installed per user. Fair enough, I now thought per computer was better anyway. The problem despite changing deployment method, it still wasn't installing. The only error I could see in GPResult for it was;

Software Installation                                   Pending

Software Installation did not complete policy processing because a system restart is required for the settings to be applied. Group Policy will attempt to apply the settings the next time the computer is restarted.

The problem with that message was no number of reboots was fixing it. So I knew it was trying to apply the policy and failing. Eventually I tried to run the MSI installer for the client manually from the network share that I was using for the deployment, thinking there was something still messed up in my permission settings and I could not access the share properly. That's when I saw the message already given in background info and realised that this was my actual problem.


Only per machine installation is allowed. Please make sure the user has appropriate rights to do so.


This message was then mirrored trying to run the installer locally.


What Didn't Fix It


A quick google revealed some people with the same issue, usually brought about in the same way, but no solution that I found. I reran the install from a local drive with the same result, so it wasn't permissions on the share or the files in the share. Not people asking on this forum I don't think, more asking on the MS side of the fence.


I tried reinstalling an older version (6.2). It installed fine. Reasoning that this may have blown some cobwebs out of the registry or elsewhere (technical terminology), I uninstalled and tried 6.3 again without luck.


I tried temporarily redoing the per user policy and setting it to remove the software when a PC fell outside the scope. Then I removed the PC from the affected OU after a number of gpupdates. Reasoning this might clean out any per user policy problem. It didn't, probably because the software was never flagged as successfully installed.


Next I tried enabling my new policy on another PC besides my own, logged on (same user account for good measure), gpupdated and rebooted. Installed fine, so my new Group Policy was a success.


At that point I gave up for a while. Time is precious midweek. Tried the newer policy on more PCs and different users and it worked, including to update existing installs. I'd only killed my own PC and I could live with 6.2 until 6.4 came out. But it nagged at me.


Today being Friday I had some time to give this a proper look again. I tried Revo Uninstaller to see if it could pick up anything while I tried to install and it didn't. I turned on Windows Installer Logging to see what I could see in there, but wasn't sure that it was helping.


I also tried removing my PC from the domain entirely, running GPUpdate to hopefully get a fresh start on group policy while off-domain and rebooting a few times, then manually installing Mimecast for Outlook as a local admin. With no joy. Going back onto the domain, still not fixed.


What Did Fix It


Goes without saying to make sure you have uninstalled all other versions of the Mimecast for Outlook client so that you run into fewer registry keys to check, but the registry is where I found it.


So I waded into the registry and this is where I fixed my problem. Standard warning, don't go messing with your registry without protecting yourself from harm, it can destroy the functionality of your computer. And if you do mess with it and delete or change keys, make sure you always back them up first (that rule I even follow). You can read about doing that most places, but it is essentially right clicking the key you want to remove or change first and selecting Export from the context menu. I didn't just delete keys blindly either, I had some clues from other forums that going after the keys I looked for would just force a redownload of only the current (hopefully correct) ones and remove orphaned ones.


So I started refining a search term for finding keys that might be causing an issue. Mimecast is not fine-tuned enough. Turns out that searching for Mimecast for Outlook 32-bit doesn't return very many false positives. Obviously substitute 64-bit if using that variant.


Unfortunately I wasn't documenting steps too well at this point, but you are looking for keys containing values with that name, you should find a couple that look like this;



Group Policy deployment keys exist in two places and are sometimes left behind when you remove a policy from GP.. (Sure, I know that NOW)


I backed up and deleted ones that had contents like in the above image from;

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy\AppMgmt\{92c82e4b-7f49-42c7-989e-be0046889589}


HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\AppMgmt\{58223c64-4409-4a20-ac79-baa75beb4b78}


Needless to say that your random alpha-numeric keys will no doubt differ from mine, but I got rid of the one starting with 92c82e4b and the one starting with 58223c64 from the above.


And then I manually installed Mimecast for Outlook 6.3 without so much as needing to reboot.


And then I uninstalled it and ran gpupdate and let it reinstall from my per computer group policy when I rebooted.


I highly suspect that it was the HKCU entry in my case that was causing the problem. But I got rid of both. It was never removed after removing the User-based policy, and any Mimecast for Outlook installation was continuing to look to this key before installing.


That's my hypothesis anyway. If I had more time I'd break another computer the same way and really follow my steps through as I went. But its Friday afternoon here and I'm going home. Please add any further tips for people in the same boat as I was.


I hope Mimecast can check out the validity of this (it does need more checking that just my observations from working through it once for it to be truly useful) and maybe add something to their Group Policy documentation about how to recover from it. It would have really helped me out, especially if I'd deployed it to the domain without doing closed test runs!

1 person found this helpful