We have a set of AR servers transactions could be executed from, and these could be using different DCs, so reading this information back from responses would be very useful for a particular need.
Thanks
We have a set of AR servers transactions could be executed from, and these could be using different DCs, so reading this information back from responses would be very useful for a particular need.
Thanks
I would get this in a policy do do some PoSh. This is the snip I use to get the DC used in the request:
$domainController = $Request.Incontrols.controls | Where-Object {$_.Name -eq "13"} | Select Value
I would get this in a policy do do some PoSh. This is the snip I use to get the DC used in the request:
$domainController = $Request.Incontrols.controls | Where-Object {$_.Name -eq "13"} | Select Value
jacob maloney_32702 Does your method work (better?) for SPML?
This works for any request that is generated by the administration service. SPML included.
If you stay on the inside where the request lives you can still get anything that is there, or add data using $Request.Get() for things like if you want another field in the set of values.
Has always seemed easiest and most powerful to do it that way. Maybe on Modify of a user scoped down to the attribute within a policy script? Write to file, attribute or event log.
I wrote a whole logging thing just for stuff like this because SPML is difficult to work with.
I guess I just usually come at it differently - i.e. in this case, domaincontroller = $Request.parameter("ldapserver")
I did not answer your question. Does it work better, I don't know.
I remember having issues with the Request object using SPML and sometimes the LDAPServer was empty.
Worth a thought for the person putting this into their ARS environment.
Thanks Jacob. Did you do anything with Script Policies at the same time to enhance the items that SPML would be able to return / or could you get more from changing the SPML body to find extra data?
Cheers