Is there a way to know the specific domain controller that has been used to perform an operation when using SPML?

I can't speak to SPML per se but I can tell you that the transaction payload (a.k.a $Request object) of every AD-centric action take by Active Roles contains a parameter LDAPServer.

In PoSh, you can obtain this value thus:

(This is an example of a script policy firing after an object is created)

Function OnPostCreate ($Request)

{

$LastTransactionDC = $Request.Parameter("ldapserver")

# Change the description of the user on the DC where they were created

Set-Qaduser -identity $Request.DN -Description "New user description" -Service $LastTransactionDC

}

Hope this helps.

Thanks Jonny, but alas this workload is SPML based and I can't change that. I can see now how to use this if its via POSH but still would like to see an equivalent ldapserver values from an SPML transaction.

So ideally, you would like the DC name in the SPML reply as it were?   I thought that might be the case.

I'm not very familiar with the SPML implementation so really don't know how practical it would be to deliver that information.  

In surfacing the existence of the information in the $Request object, I thought you might have an option to go and harvest it somehow after the fact.  FWIW, it's not stored in the Change History out of the box but it could be added easily by a Change Workflow reacting to the user create transaction and injecting the LDAPServer name into the OperationReason of the user create request.  You could then mine the Operation reason out of the Change History. 

There is an assumption I am making though is that when the transaction is initiated via SPML that the same option exists to intercept the $Request and modify it.

Food for thought anyway.

So ideally, you would like the DC name in the SPML reply as it were?   I thought that might be the case.

I'm not very familiar with the SPML implementation so really don't know how practical it would be to deliver that information.  

In surfacing the existence of the information in the $Request object, I thought you might have an option to go and harvest it somehow after the fact.  FWIW, it's not stored in the Change History out of the box but it could be added easily by a Change Workflow reacting to the user create transaction and injecting the LDAPServer name into the OperationReason of the user create request.  You could then mine the Operation reason out of the Change History. 

There is an assumption I am making though is that when the transaction is initiated via SPML that the same option exists to intercept the $Request and modify it.

Food for thought anyway.