MIM2016 Upgrade Hanging on Custom Action – SetPermissionEval

I was upgrading a client’s environment from FIM2010 R2 to MIM2016, during the upgrade of the Synchronization service, the installer appeared stuck, I waited for over an hour, there was no activity and no progress update. I checked the msi installation log, and found the last activity was CustomAction = SetPermissionEval, ActionType=3073. Other than this, there was no errors or any indication of failures.

msilog

According to this TechNet article, SetPermissionEval sets access permission (ACLs) for file folders, registry, DCOM launch/access permission and WMI.

ExtensionsCache

So I opened the Process Monitor, I discovered the reason was the hidden folder Microsoft Forefront Identity Manager\2010\Synchronization Service\ExtensionsCache, this directory contained over 260,000 folders with approximately 2 million objects, the SetPermissionEval custom action was applying ACL on each of them!

procmon

I couldn’t find the exact purpose for the ExtensionsCache, there is no Microsoft documentation on it nor any mention in the official upgrade guidance or best practice, however by looking at the contents of the folder, I suspect FIM/MIM creates these folders when running synchronisation or export using custom code based extension rules.

Based on an earlier forum post, I decided to delete the contents in this folder

delete

Once all the items are deleted, I restarted the synchronization service upgrade, the upgrade continued and finished without delay.

I still don’t understand why the installer file should try to set the file permission in the cache directory, when the whole directory content could be removed without problem, why brother?

Anyway if you are upgrading or patching your FIM or MIM instance, it might be worthwhile to check your ExtensionsCache hidden directory, if you have too many folders there, stop the synchronization service and delete those cache folders to avoid this problem.

Mobile Application Management (MAM)

The biggest challenge for BYOD devices is data security and leakage, a common method to enforce data protection is through Exchange ActiveSync and/or Mobile Device Management (MDM) tools such as AirWatch, Intune and others.

Both ActiveSync and MDM comes with the option of device wipe and enforcing device PIN. If the device is lost or the employee is terminated, the company could remote wipe the device to protect its data. While device wipe is great from the company’s perspective, it is almost always met with resistance from the employees because everyone fears the company has the power to wipe their personal data such as photos and contacts from their own personal devices.

What are the options when users do not use MDM:

Option 1: block access if not using a managed device, which makes sense from a security perspective but not so good from a productivity perspective.

Option 2: allow user to access using a thin client, for example OWA for email where the user enters the OWA URL into their browser and then their credentials, the email is stored on the server rather than on the client. The risk with this approach is:

  1. on a personal device many users do not use PIN or encrypt the device, anyone may be able to access the device if stolen
  2. user often saves the credential on their personal device so they don’t have to enter the password each time, this will also allow unauthorised users to see the previously browsed sites such as OWA.
  3. while Multifactor Authentication (MFA) can be enabled, if the smart phone is the 2nd factor, effectively the phone factor is bypassed when the same device is compromised.

Option 3: utilise Mobile Application Management (MAM). The security policy is applied at the application level instead of the device level. Data wipe will now be performed at the application level (AKA selective wipe). This will remove the corporate data while leaving the personal data intact.

MAM with Microsoft Intune allows a company to control:

  • cut/copy/paste restrictions
  • prevent “save as”
  • prevent cloud backup
  • jailbroken or rooted devices
  • PIN requirement
  • selective wipe of the application data

The screenshot below illustrates some of the security options available:

mam1a

Some of MAM supported apps are show below, for the complete list go to Microsoft Intune Partners page.

mam2b

 

To deploy Intune MAM, users will need either Intune or EMS licenses.

It is also possible to deploy both Intune MDM and MAM at the same time. A scenario for this is to allow corporate devices to be managed by MDM, and offering BYOD users a choice between MDM and MAM.

Microsoft TechNet has further information on Intune MAM

How you can protect app data

Create and deploy mobile app management policies with Microsoft Intune

End user experience