MIM 2016 Upgrade to MIM 2016 SP1 Fails on Second FIM Service Server

Weird one: the upgrade to SP1 on the first MIM Service server went OK (a few hiccups with a missing data type in SQL, but I was able to create those and the upgrade went fine).

However, the installation on the second MIM Service server failed with very little information of any use in the log file.

I decided to uninstall MIM and got an error that the web application at “http://mysite.mydomain.com” did not exist. Sure enough, that Alternate Access Mapping was missing in SharePoint Central Admin on the second MIM Service server’s SharePoint configuration. I stopped the uninstall, added the AAM and the SP1 Upgrade finished successfully.

FIM: Send notification to requestor when request is approved

We needed to send a notification to the requestor when the request was approved. Out of the box, the approval workflow will send a notification to the requestor on rejection or expiration of the request, but not on approval. (That notification goes to the approver.)

After a little thinking, it wasn’t too hard to do.

1. Created the appropriate email template with what we wanted to communicate to the requestor.

2. Created a set of “ApprovalResponse” objects with a Decision of “Approved” and a display name that started with “Update to Group”.

3. Created a workflow with a notification activity. This was the only tricky part. The UI did not let us have [//Target/Requestor] as the recipient. We created the initial workflow and then edited the XOML via the “Extended Attributes” tab to change the recipient to [//Target/Requestor].

4. Created a management policy rule of “Request” type. The set of requestors is a set that only includes the FIM Web Service account (which is the account that originates the creation of the Approval Response object. The action was “Create” and the target resource was the set we created in step two. The policy workflow was the one we created in step 3.

Enable-CSUser Insufficient Permission

Enabling users from both the Lync control panel and PowerShell was producing this error:

“Active Directory operation failed on “abc.domain.com”. You cannot retry this operation: “Insufficient access rights to perform the operation
00002098: SecErr: DSID-03150E8A, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
“.You do not have the appropriate permissions to perform this operation in Active Directory. One possible cause is that the Lync Server Control Panel and Remote Windows PowerShell cannot modify users who belong to protected security groups (for example, the Domain Admins group). To manage users in the Domain Admins group, use the Lync Server Management Shell and log on using a Domain Admins account. There are other possible causes. For details, see Lync Server 2010 Help.”

Most solutions to this topic mention ensuring that Inheritable Permissions are set on the user’s security tab in AD, but in our case these were already set.

A user with Domain Admin privileges could enable the users but not our Lync Admin account that had both CSAdministrator and RTCUniversalUserAdmins membership.

After much head scratching, it turned out that the Lync server had been removed from the membership in the RTCUniversalUserAdmins group. Adding the computer back to that group was the solution.

Sharing internet connection with Hyper-V client

Had to do this a little differently than all of the blog posts I’d seen because using an Internal virtual switch and trying to allow it to share my local network resulted in an IP address conflict.

The fix was to create an External virtual switch with “Allow management operating system to share this network adapter” checked. Creating this takes a minute and Internet connectivity is dropped for a second while it applies changes.

Then, in the VM settings, select this new switch as the network adapter.

The VM might need to be turned off when making this setting change, but it worked for me while the VM was running.

FIM Workflow Updating Items with Enumerate Resources Activity

There is a great write up on how to use the enumerate Resources Activity to update items in FIM here: http://www.fimspecialist.com/fim-portal/custom-workflow-examples/custom-workflow-example-enumerate-resources-activity/

I only had to do one thing differently to get it working in my environment. In the designer.cs file, I commented out the line:


and instead add the activity on the enumerateResourcesActivity:


Unrelated to the post that explains updating objects with enumerateResourcesActivity, I got a rather misleading error when executing the update: “CompositeActivity cannot transition to ‘Closed’ status when there are active child context still exist for child activity.”

Apart from the confusing grammar, I assumed something was wrong with the sequence I was using to update the object. It turned out to be much simpler: I had a typo in one of the attribute names I was updating. I think this error is thrown if the update fails and the activity doesn’t get to close.

SharePoint: Allow web part to use System.DirectoryServices

A web part I developed needed to access Active Directory. A lot of posts say to just set the site’s trust level to Full, but that is a security risk.

The solution I found was to use a wss_custom trust level.

First, I copied the wss_minimal.config file in the CONFIG file of the 14-hive and named it wss_custom.config.

I then modified it as described in this post: http://www.derkeiler.com/Newsgroups/microsoft.public.dotnet.security/2004-10/0240.html

I added this to <SecurityClasses>:

< SecurityClass Name=”DirectoryServicesPermission”  Description=”System.DirectoryServices.DirectoryServicesPermission,  System.DirectoryServices, Version=1.0.5000.0, Culture=neutral,  PublicKeyToken=b03f5f7f11d50a3a”/>

Then I added the “DirectoryServicesPermission” to the “NamedPermissionSet” of “ASP.NET”:
<PermissionSet class=”NamedPermissionSet” version=”1″  Name=”ASP.Net”>
<IPermission class=”DirectoryServicesPermission” version=”1″  Unrestricted=”true”/> 

[Note: I didn’t remove the other entries in those two sections.]

In the web.config file, I added this to the <securityPolicy> settings:

<trustLevel name=”WSS_Custom” policyFile=”C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\config\wss_custom.config” />

Next, I changed the trust level in the web.config file to WSS_Custom.

<trust level=”WSS_Custom” originUrl=”” />

[In addition to the post referenced above, this post helped me understand the steps to use a customized Code Access Security policy: http://blog.tylerholmes.com/2008/11/creating-custom-cas-policy-file-for.html]

In my web part C# code, I used PrincipalContext with a user with appropriate AD permissions:

PrincipalContext cxt = new PrincipalContext(ContextType.Domain, sDomain, sUser, sPwd);

using (UserPrincipal user = UserPrincipal.FindByIdentity(cxt, sAccountName))


DirectoryEntry entry = user.GetUnderlyingObject() as DirectoryEntry;

DirectorySearcher searcher = new DirectorySearcher(entry);


searcher.Filter = “(&(objectClass=user)(|(sAMAccountName=” + sAccountName + “)))”;

SearchResult result = searcher.FindOne();

if (result == null)


litResult.Text += “Error: User not found.”;




//do something