Installing MIM 2016 on a named SQL instance with a non-standard port

mim_logo

FIM 2010 and MIM 2016 have a thing in common with regards to SQL named instances; they can’t handle the truth.  In this case they can’t handle that the SQL instance is running on a port other than the default 1433 SQL port.

What do you do when you have have a friend that can’t handle the truth but that you don’t want to lie to?  You tell them as much of the truth as they can handle and that’s exactly what we need to do for MIM.

In this case, truth comes in the form of an SQL alias, your friend MIM will never know the truth that it’s actually talking to SQL on a port other than 1433.  Shocking!

Note: The SQL alias needs to be created in both the 32-bit and 64-bit versions, your 32-bit applications will use the 32-bit alias while the 64-bit applications use the 64-bit one (obviously).
If one application works with the alias while another one doesn’t its usually an indicator that there’s a difference between the 32-bit and 64-bit aliases in your setup.

For testing and troubleshooting purposes it is useful to create an empty file with a .udl extension, for example test.udl, and then double-click that file to launch it.

A Test .udl fileudl2

Make sure you’re testing the same provider that your application uses, the current version of the MIM Setup program seems to use the SQL OLE DB provider rather than the SQL Server Native Client.

You also need to make sure that the application you’re testing with supports the cryptographic ciphers and algorithms being used on the server end, for example; if the application requires a version of TLS that is disabled on the server side then you need to either get an update to the application or enable the cipher on the server side.

Continue reading

Integrating SAP Web Services with MIM – part1

SAP

I recently finished a successful integration project for a customer where they were moving from FIM 2010 to MIM 2016 and from the legacy SAP Management Agent to the current SAP Web Services Management Agent – the following are observations from the journey.

The default projects published for the SAP Web Services Connector contain VB for Workflows code, rehosted so you don’t need Visual Studio to edit it but the drawback is that you’re limited to editing it inside the accompanying Web Services Configuration Tool (which is a bit….dated, frankly).  Documentation for it is also very limited and hasn’t been updated since the original release of the client.

The files discovery.xml and generated.config (or cfg.config in the older version) inside the .wsconfig project can be edited using 7-Zip or similar if you need to tweak settings that currently can’t be configured inside the WSConfig tool, such as increasing the HTTP timeout value of the Web Services Connector, the default timeout being 60 seconds (standard Caveat Emptor warnings apply to modifying the content).

Note that the generated.dll file inside the .wsconfig project is re-compiled when you make changes to the Discovery settings inside the WSCONFIG tool, which in turn overwrites any manual changes made to the generated.config file so you’ll need to redo the manual changes whenever a change to the Discovery settings in the project is made.

Also, make sure you have downloaded the latest SAP Web Services Connector from Microsoft, see the Wiki on MIM Management Agents.

Be aware that since the latest versions of the Web Services connector changed build numbers from 5.3.x.x to 1.x.x.x you may need to uninstall older versions of the SAP Web Services Connector since the Windows Installer logic will reject the lower build version numbers as it (quite logically) believes it to be an older version of the connector.

For the Employee object in SAP, the following Standard SAP BAPI functions are being referenced in the pseudo-VB code and the generated.dll file that live inside the .wsconfig project that comes with the SAP Web Services Connector:

Employee:

Full Import:
BAPI_EMPLOYEE_GETDATA
BAPI_ADDRESSEMPGETDETAILEDLIST
BAPI_PERSDATA_GETDETAILEDLIST

Export/Replace
BAPI_EMPLOYEE_ENQUEUE
BAPI_PERSDATA_GETDETAIL
BAPI_PERSDATA_CHANGE
BAPI_EMPLOYEE_DEQUEUE
BAPI_TRANSACTION_COMMIT

The latest SAP Web Services Connector template (2016-03-02) expands the number of SAP object types to also include pseudo-VB code for the following object types:

 _OrganizationUnit ()

Full Import:
BAPI_PDOTYPES_GETDETAILEDLIST
BAPI_ORGUNITEXT_DATA_GET

PrimaryGroup ()

Full Import:
 RFC_READ_TABLE

Export Replace:
 RFC_READ_TABLE
BAPI_USER_GETDETAIL
BAPI_USER_CHANGE

 SecondaryGroup ()
Full Import:
RFC_READ_TABLE

Export Replace:
RFC_READ_TABLE
BAPI_USER_GETDETAIL
BAPI_USER_CHANGE

Profile ()
Full Import:
 BAPI_HELPVALUES_GET
RFC_READ_TABLE

Export Replace:
RFC_READ_TABLE
BAPI_USER_GETDETAIL
BAPI_USER_PROFILES_ASSIGN

Role ()
Full Import:
 BAPI_HELPVALUES_GET
RFC_READ_TABLE

Export Replace:
RFC_READ_TABLE
BAPI_USER_GETDETAIL
BAPI_USER_ACTGROUPS_ASSIGN

User ()
Full Import:
 BAPI_USER_GETLIST
BAPI_USER_GETDETAIL

Export Add:
BAPI_USER_CREATE1

Export Delete:
BAPI_USER_DELETE


Export Replace:
BAPI_USER_CHANGE

Password:
BAPI_USER_UNLOCK
 BAPI_USER_CHANGE
SUSR_USER_CHANGE_PASSWORD_RFC

 

Importing using the Standard BAPI calls from SAP and the default project from Microsoft turned out to be quite slow as we discovered after the initial deployment.  The default project is using the standard BAPI calls to parse through a list of all users in the alphabet to import one entry from SAP at a time – which is probably part of the performance issue.

Fortunately, the local SAP-consultant I was working with on this project had written a custom BAPI which was collecting the users being imported into a table of rows and then sending it over the wire in one batch – we ended up dumping all the VB-code from Microsoft from the original default Web Services project and only using it for reference in a new web service project I wrote specifically to use the new custom BAPI.

In short; The performance boost from using the custom BAPI to communicate with SAP Web Services was staggering – an Import operation from SAP Web Services to the MIM Connector Space that took 6 hours with the standard BAPI calls now takes ~3 minutes using the custom BAPI.  I’ll go further into this in part 2 of this series.

 

Further details:

BAPIs – Definition
http://help.sap.com/saphelp_46c/helpdata/en/a5/3ec8464ac011d1894e0000e829fbbd/content.htm

MIM and SAP Web Service Connector Timeouts
http://social.technet.microsoft.com/wiki/contents/articles/13675.fim-full-import-on-a-sap-web-services-management-agent-fails.aspx

Integrate SAP HR and Active Directory using Forefront Identity Manager (FIM) SAP Connector for WS

 

Sudden Access Denied in Group Join Approval Workflow in MIM 2016

On a Windows Server 2012 R2 server, running latest version of MIM 2016 on SPS Foundation 2013 with roll-ups; after editing the default Owner Approval workflow I started to get the following error when attempting to Join or Leave any groups with Ownership Approval:

JoinError1Error details:
JoinError2

I cried, then I cried some more.  Then I went and visited Mr. Google (What if Google was a Guy?) and stumbled upon this gem from the Technet forums that turned out to be the resolution… yes, it’s a FIM bug that’s still in MIM… not a feature 🙂

Error message from Event ID 3:

Microsoft.ResourceManagement.Service: System.NullReferenceException: Object reference not set to an instance of an object.
at Microsoft.ResourceManagement.Workflow.Hosting.HostActivator.ActivateHost(ResourceManagementWorkflowDefinition workflowDefinition, Boolean suspendWorkflowStartupAndTimerOperations)
at Microsoft.ResourceManagement.Workflow.Hosting.WorkflowManager.StartWorkflowInstance(Guid workflowInstanceIdentifier, KeyValuePair`2[] additionalParameters)

 

When a new approval workflow is created and approval activity is placed in this workflow it contains the following element in a XOML definition:

(…)

xmlns:ns1=”clr-namespace:System.Workflow.Activities;Assembly=System.WorkflowServices, Version=3.5.0.0 (…)

Pre-Edit

Above is from the standard approval workflow delivered with FIM that works out of the box, after editing the standard workflow or in any custom authorization workflow you create it changes to the following:

Post-Edit

(…) xmlns:ns1=”clr-namespace:System.Workflow.Activities;Assembly=System.WorkflowServices, Version=4.0.0.0, (…)

 

JoinSuccess1

…Editing the XOML in Extended Attributes and changing it back to 3.5.0.0 and saving the workflow resolves the issue.  The bad news is it breaks again the next time you do any editing of the workflow 🙁

 

Details:

https://social.technet.microsoft.com/Forums/en-US/1b76672d-1276-4c71-b9fc-5bb1fcb36877/event-id-3-with-approval-activity?forum=ilm2