When somebody has a chance, can you please create a 64-bit installer for this?

No rush as x86 works fine, just means I have to copy files which is a bit of a pain

Cheers

Microsoft has announced a number of features are to be deprecated in "the next FIM version" as described at http://technet.microsoft.com/en-us/library/jj879229(v=ws.10).aspx. In particular, the following need to be updated:

• IDB-312 - ECMA2 support
• Updating the default run profiles for the xMA such that they do not contain single step run profiles (ie. "full import and full synchronization")

If you run an export with the Identity Broker service disabled, every item will attempt to export and fail. Instead, service availability should cause the export to fail at the BeginExport level, like the AD and SQL MAs.

Decimal and Single values are registered as Numeric values in FIM, but floating point values are not supported by the Numeric valuetype - this results in errors on FIM full imports; namely:

'invalid-numeric-value'

Hey Guys,

I've uncovered a new issue with IDB in regards to renames.

This issue occurs when multiple renames are perfomed on the same object. I've performed a significant ammount of testing and analysis on this issue, which i'll explain in detail below, but in each case, after the second rename, the confirming import in FIM produces one or more need-full-object errors. I also believe I have determined where the issue is being produced.

In most cases, this is the general procedure for producing the issue:

1. Rename user (uid) in Active directory and produce a Provisioning Rename for Export to TAM.
2. Export rename to TAM (Successfull)
3. FIM Delta Import confirms rename. (Successfull)
4. Rename same user again in AD.
5. Export rename to TAM (Successfull)
6. FIM Delta Import - need-full-object error produced.

In each case the rename is successfully exported to TAM, and i have confirmed that in all cases the Modify Anchor method on the connector is being hit.

These are the cases tested, and the results:
(All UNIFYDelta files for these cases are in the attached ZIP)

1. - Rename user cladn3 to cladn30, and then rename back to cladn3.
2nd Import Result - need-full-object error produced on cladn3

2. - Rename user kxhep0 to kxhep50, and then rename again to kxhep70.
2nd Import Result - need-full-object errors produced on both kxhep70, and kxhep0

3. - Rename user uxngt0 to uxngt05. Perform an IDB full import, then rename user back to uxngt0.
2nd Import Result - need-full-object error produced on uxngt0

4. - Rename user ulgni1 to ulgni10. Perform a FIM full import, then rename user back to ulgni1.
2nd Import Result - need-full-object error produced on ulgni1

5. - Rename user ugfen1 to ugfen10. Perform an IDB & FIM full import, then rename user back to ugfen1.
2nd Import Result - need-full-object error produced on ugfen1

6. - Rename user bxttt0 to bxttt05. Drop IDB Connector Partition and FIM CS, then Reimport. Rename user back to bxttt0.
2nd Import Result - Rename successfull.

The need-full-object error is defined here: http://support.microsoft.com/kb/818559
We've seen this error before on QDET-156, and it occurs when an update operation is attempted on an object before the object is sucessfully renamed. The rename is completed by the presence of a moddn operation in the delta ldif file. Until this operation is processesd, the object in FIM retains it's original DN.

In viewing the UNIFYDelta ldif files produced on the second confirming import, the issue becomes apparant.

In the cases where the uid was changed back, no moddn entry is present to confirm the rename. Updates present for the object fail with the error as explained above.

In case 2, where the uid was renamed again to a different uid, the ldif file did contain a moddn, but it was incorrect. As above in this case, the first rename was from kxhep0 to kxhep50, and the second from kxhep50 to kxhep70. The second moddn (see below) was trying to rename from kxhep0 to kxhep70.

The moddn for the first rename in this case looked like this:

dn: UID=kxhep0,CN=Users,DC=DET,DC=QLD,DC=GOV,DC=AU
changetype: moddn
newrdn: UID=kxhep50
deleteoldrdn: 1
newsuperior: CN=Users,DC=DET,DC=QLD,DC=GOV,DC=AU

This is correct, and the rename was successful.

The second rename:

dn: UID=kxhep0,CN=Users,DC=DET,DC=QLD,DC=GOV,DC=AU
changetype: moddn
newrdn: UID=kxhep70
deleteoldrdn: 1
newsuperior: CN=Users,DC=DET,DC=QLD,DC=GOV,DC=AU

This is incorrect, as it is trying to rename from kxhep0 to kxhep70, but at this point in FIM, the DN is kxhep50.

After seeing this error, i performed some analysis on the database to monitor the status of the records around a simlilar operation. In this case i renamed a user from uxnnt3 to uxnnt30, and then to uxnnt31.
The results of this trace are in the attached excel sheet, but i was able to note that throught all of the exports and imports, the DN field on the entity table remained unchanged from it's initial state.

The fact that this field is not being updated explains all of the above issues. When the uid is being renamed as in case 2, it produces a moddn from the DN present, to the required DN. In cases where the uid is being changed back, as it allready has the same value in the DN field, it does not produce a moddn as assumes none is required.

It looks like this field is used to create the moddn entry, particularly in specifying the current DN of the object. On the second rename, the moddn entry is produced incorrectly, as the DN was not updated after the first rename. The result of this is that the rename is not confirmed on the FIM import, and remains in the state of awaiting export confirmation.

To summarise all of the above, i've confirmed that on rename operations within IDB, the DN field of the entity table is not updated to reflect the new DN of an object. The result of this causes issues when creating the moddn entries after a second object rename.

The downloaded transformed configuration files are missing their file extension.

Has the MIME type been set on these files?

Can the labels mentioning XSLT be renamed to configuration documentation? Or something along those lines, as XSLT is a technical term. This is on the connector and adapter pages tooltips, as well as the header for the page once configured.

Thanks.

When the import file cannot be generated it is unclear what has happened.
Namely the following is what can be seen from the Event Viewer on the FIM side:

The extensible extension returned an unsupported error.
 The stack trace is:
 
 "System.Exception: Error encountered attempting import: System.ServiceModel.CommunicationException: An error occurred while receiving the HTTP response to http://localhost:59990/IdentityBroker/FIMLDIFAdapter.svc. This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down). See server logs for more details. ---> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
   at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
   --- End of inner exception stack trace ---
   at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
   at System.Net.PooledStream.Read(Byte[] buffer, Int32 offset, Int32 size)
   at System.Net.Connection.SyncRead(HttpWebRequest request, Boolean userRetrievedStream, Boolean probeRead)
   --- End of inner exception stack trace ---
   at System.Net.HttpWebRequest.GetResponse()
   at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
   --- End of inner exception stack trace ---

Server stack trace: 
   at System.ServiceModel.Channels.HttpChannelUtilities.ProcessGetResponseWebException(WebException webException, HttpWebRequest request, HttpAbortReason abortReason)
   at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
   at System.ServiceModel.Channels.RequestChannel.Request(Message message, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
   at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]: 
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at Unify.Product.IdentityBroker.IdentityBrokerLDIFAdapter.ILDIFAdapter.ImportAll(Guid adapterId)
   at Unify.Product.IdentityBroker.IdentityBrokerManagementAgentProxy.GenerateImportFile(String fileName, String connectTo, String user, String password, ConfigParameterCollection configParameters, Boolean fFullImport, TypeDescriptionCollection types, String& customData) 

   at Unify.Product.IdentityBroker.IdentityBrokerManagementAgentProxy.GenerateImportFile(String fileName, String connectTo, String user, String password, ConfigParameterCollection configParameters, Boolean fFullImport, TypeDescriptionCollection types, String& customData)
Forefront Identity Manager 4.0.3606.2"

whilst the following is what is available in the IDB logs

An exception has occured whilst performing a job for adapter 2656b225-d789-437d-bd32-03ae2f6ed07c job GetTransformedEntities (ParallelGate):
System.Data.ConstraintException: Only standard components can be contained inside a multipart component.
at Unify.Product.IdentityBroker.EntityMultiPartDistinguishedNameComponentGenerator`2.<>c__DisplayClassa.<GetDistinguishedNameComponents>b__9(IEntityDistinguishedNameComponentGenerator`2 generator)
at System.Linq.Enumerable.<>c__DisplayClass12`3.<CombineSelectors>b__11(TSource x)
at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()
at System.Linq.Buffer`1..ctor(IEnumerable`1 source)
at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source)
at Unify.Framework.IO.DistinguishedNameMultiPartComponent.ToString()
at System.Linq.Enumerable.WhereSelectArrayIterator`2.MoveNext()
at System.Linq.Buffer`1..ctor(IEnumerable`1 source)
at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source)
at Unify.Framework.IO.DistinguishedName.GetStringValue()
at Unify.Product.IdentityBroker.Repository.AdapterEntityContext.SetEntityRowDetails(__EntityInsertRow row, IAdapterEntity entity, EntityDataContext sourceContext, IEntityCollectionKeyUtility`1 keyUtility)
at Unify.Product.IdentityBroker.Repository.KnownEntityContextBase`4.InsertItems(HashSet`1 addedItems, EntityDataContext sourceContext, SqlConnection connection)
at Unify.Framework.Data.LinqContextConversionBase`4.SubmitChanges()
at Unify.Framework.ParallelGate.ParallelGateJob.RunBase()
at Unify.Framework.AsynchronousJobExecutor.PerformJobCallback(Object state)

Failing exports aren't being picked up as failures in FIM.
To easily reproduce, try exporting to a disabled adapter.

Containers are an important part of interaction with FIM (see IDB40:Containers), but they aren't mentioned on the IdB UI anymore. "container" should at least be present as an additional object class on the xMA generator as it was in v3.

The default run profiles installed when you deploy an instance of any Identity Broker 3.* MA for FIM include combined "single step" run profiles as has been "best practice" dating back to MIIS days (see http://social.technet.microsoft.com/wiki/contents/articles/1147.aspx#Single_step_vs_multistep).

However, advice from Jeff Nelson recently after explaining anecdotal evidence of "stopped-server" problems experienced @ DEEWR, is that the Microsoft FIM Product Group is planning to deprecate support for this model entirely in favour of combined "multi step" run profiles. I spoke directly to Andreas Kjellman (MS Sync engine product lead) last month and he backed this up ... the bugs that they are now aware of with this style of run profile are "too much to even try fixing", and so they're going to remove support for them. They claim that they are the main cause of the stopped-server errors @ DEEWR, and I can vouch for this with my own experience, particularly with the FIM MA.

While the above sounds very much like a cop-out, there is certainly pros and cons of both approaches. The very BIG downside of losing the single step model entirely is the corresponding additional overhead that will be incurred in any CS where there is a large number of disconnectors (since a single step model was the only way until now of avoiding repeated reprocessing of these disconnectors with every DI/DS). Now we have to live with this overhead, it will become beholdent on FIM solution designers to minimise the number of disconnectors, which in itself is already an established best practice anyhow.

Needless to say, with this in mind, and the increasing likelihood of UNIFY PS staff running into the same error themselves, it would be a good idea to change the default run profile definitions installed by the Identity Broker MA wizard assp.

On the subject of this same error, there are many potential causes, and this is only one of them. Another is trying to run ANY OTHER RUN PROFILE while a FIM MA run profile is already executing - this will almost always cause the FIM MA run profile to fail!

In the meantime I have already ensured that I have manually changed all FIM run profiles to adapt to this new multi-step standard.