‘The security database on the server does not have a computer account for this workstation trust relationship’ when trying to log on via RDP to a customized VM in Azure.

Last summer, our customized lab VM’s started having issues after updating from Windows Update and applying the latest fixes.

The error message received was ‘The security database on the server does not have a computer account for this workstation trust relationship’ when trying to log on via RDP.

After extensive troubleshooting we determined that this seems to have been caused by changes which renamed the VM internally, either in Azure Resource Manager, the Windows Update code or the version of the Azure IaaS agent running on the VM’s.

At any rate… as the server was a domain controller, when it renamed itself to match the external name of the VM it caused an identity crisis as it could no longer find itself.

Yes… the technically correct answer from the handbook is to Sysprep/Generalize any image/template VM that you deploy to Azure but for a lab scenario you sometimes want to have a specialized image that contains AD & Friends – and AD and Sysprep are just not friends as Sysprep will eat AD and not even leave a skeleton behind.

Prior to June this year, deploying a customized non-sysprepped VM from an image with a new name to Azure Resource Manager did not change the actual computer name inside the image if the VM was a domain controller.

This meant you could deploy the same lab image multiple times to Azure with a different external VM name but the name of the VM inside the OS would stay the same.

At some point between June and August this year there seems to have been a change to this which was affecting the image, after updating from Windows Update the name of the server inside the VM was now being changed to match the external name.

This in turn resulted in it being impossible to log on to the VM after rebooting, as the actual computer name of the domain controller VM in the AD that it hosts isn’t changed to the new name at the same time.

TLDR: Redeploy the VM using the original VM name, run Windows Update and update without problems.  Create a new image from the updated VHD as a new template VHD.

I’ve tested a couple of different deployments after updating the specialized image and it doesn’t look like there is an issue updating from Windows Update using the new template that contains the latest updates, even if deployed again using a different name.  Either the rename is dependent on a specific component being updated or possibly it’s related to the version of the Azure agent running on the VM.

The Domino Effect: ‘extensible-connector-refresh-required’

Symptoms: MIM Domino MA run operations return the error message ‘extensible-connector-refresh-required’

Cause: Updating the Domino MA requires the COM interface on it to be refreshed

Resolution: Open the Domino MA in the MIM Sync MMC and press OK, the MA will start refreshing the COM interface (and the user will need to press OK 4 more times as the MA cycles through different sections for updates).

Lesson: The Domino MA doesn’t have a ‘Refresh Interface’ button like a standard normal ECMA2 would, if you open the MA configuration and press OK rather than Cancel it detects the refresh requirements and initiates a refresh.

Details:

https://social.technet.microsoft.com/wiki/contents/articles/19101.fim-reference-refreshing-interfaces-of-ecma-2-0-version-of-lotus-domino-ma.aspx

 

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

 

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

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

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.