Profile photo of Ingólfur Arnar Stangeland

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

Profile photo of Ingólfur Arnar Stangeland

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

 

Profile photo of Ingólfur Arnar Stangeland

Things to consider when enabling the AD Recycle Bin

Recycle Bin

#1 check if you have any applications that use the DirSync control and make sure you have applied the NTDS hotfix from KB979214 to Domain Controllers (if you are running Windows 2008 R2 DC’s) as this changes the default behaviour of the relevant LDAP search control when returning values for objects that reference recycled (soft deleted) objects.

#2 read the ASKDS article on best practices for implementing the AD Recycle Bin.

#3 figure out if you have any critical applications using the DirSync control that can’t handle the isRecycled attribute state for objects that have been soft deleted.

 

ILM 2007 will unfortunately not be able to handle the AD Recycle Bin but FIM 2010 with Update 1 will (ILM 2007 being out of support for more than a few years now should also really be reason enough to upgrade to at least FIM 2010 R2 or MIM 2016).

Applications that have the potential to be impacted negatively by enabling the AD Recycle Bin are most likely going to be older product versions that focus on directory synchronization or monitoring using the Dirsync control.  Those will either need to be retired or updated to a newer version (older GALSync and MIIS instances probably fall under the same unsupportable hat as ILM 2007).

 

Additional links:

Polling for AD Changes using the DirSync control
https://msdn.microsoft.com/en-us/library/windows/desktop/ms677626(v=vs.85).aspx

FIM 2010 Update 1
https://support.microsoft.com/en-us/kb/978864

The DirSync control search does not return the deactivated linked attributes from a modified object in a Windows Server 2008 R2-based domain
https://support.microsoft.com/en-us/kb/979214

Using the DirSync Control
http://blogs.technet.com/b/isrpfeplat/archive/2010/09/20/using-the-dirsync-control.aspx

PowerShell DirSync Sample
http://dloder.blogspot.is/2012/01/powershell-dirsync-sample.html

Profile photo of Ingólfur Arnar Stangeland

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

Profile photo of Ingólfur Arnar Stangeland

Unexpected timeout issue when updating FIM 2010 to latest roll-up package

ExtensionsCache-Issue2This one came as a surprise – the setup of the latest FIM 2010 roll-up was repeatedly timing out and Event ID: 6311 and 6401 kept popping up in the Application log during the operation.

After a couple of pints of coffee I eventually decided to run Procmon from Sysinternals to peek at what was going on while the setup was apparently sitting around doing nothing.

Turns out there were 521,750 ghost items with names such as Sync Rule Callout <GUID> and Common MA Callout Extension>GUID> hanging around in the hidden ExtensionsCache folder under the Synchronization Service installation directory.

Stopping the FIMSync Service prior to deleting the ghost items not only allowed the update to proceed but also markedly improved performance on the MA’s on the box by at least a factor of ~3.