Dynamic groups and powershell

(concern) I strongly recommend to follow MSFT and do all Exchange management through Exchange door by calling Exchange ps1 cmdlets: this way you enforce Exchange-side policies.
Contrary, by calling LDA/ADSI to manage Exchange attributes you may hit violation of Exchange-side policies.

Note, by setting Exchange related VA attribute via "QAD-xxx" cmdlet, AR might trigger Exchange cmdlets on back-end anyway (remote for EX2010 SP? and later).

Hi I'm not proposing that anyone edits the attributes directly, only to use the ARS commandlets designed to do this. The discussion above was about the enhanced functionality - here is the enhancement request TF00414390, so that you can tell ARS not to keep the mail and primarySMTP address in sync. Instead of fixing it they just gave me the option to disable the sync because they were not checking the address I was setting ( well not me the ServiceDesk ) and it would just update the primarySMTP address and this could cause a duplicate to exist. ADU&C does not do this so they effectively made it work the same way. I actually think it was a good feature to allow the primarySMTP address to be changed just by editing the mail attribute on the general tab as lots of people do this not understanding that the primarySMTP address is actually one of the proxyAddresse types and it not really the mail attribute.

(concern) doing via Exchange cmdlet door enforces email, proxyAddresses uniqueness in Exchange Org(might include separate domains and forests).
Doing ADSI/LDAP: ARS will need to check uniqueness of added email, proxyAddress in all Exchange Org (all domains and forests registered and *not* in ARS - which might easy fall out of deployed ARS scope (will need to write your own script policy and enumerate list of All Domains in the Exchange Org)

ARS uses PowerShell remoting to update exchange attributes so I use this functionality where I can.

Loading the Exchange Commandlets is time consuming and whilst is fine for a scheduled task it's impractical to do it in an ARS policy.

It does not sound like you are confident that the underlying ARS code that calls the exchange commandlets works as expected.

If the recommendation is to always load the exchange commandlets then it would be nice if Quest gave us a way of doing this once and leaving them in memory for all scripts to use. We could then leverage the faster MS AD commandlets.

I had resigned myself to loading the exchange commandlets and requesting additional rights were added to my admin account but what JQ suggested was a way of triggering ARS to add email to the group which is what I needed and was a brilliant lateral thinking suggestion!

You may be reading more into Aidar's comments than there is.

I think it really depends on what you need to do. If your requirement falls into the regular Exchange management tasks that AR supports through the GUI (e.g. mail enabling, mailbox enabling etc.) then the embedded code in the AR service (along with the VAs that trigger it) should do the job just fine.

I completely agree with you that establishing remote PoSh sessions for Exchange operations is tedious but I guess sometimes it's a necessary evil.

What I have found equally troublesome when writing scripts is the timing issues you can run into it where your script "gets ahead" of AD and Exchange and an object isn't fully baked yet when your script goes to perform its next operation. This is where relying on the internal Exchange functionality of the AR service comes in handy because I believe it's built to account for/compensate for that.

We are on the same page here.

By setting in AR (MMC, WI, PS1 cmdlet) edsaEstablishGroupEmail, edsva-MsExch-ApplyEmailAddressPolicy - it forces AR to trigger EX PS cmdlet on back end.
(AR design standard trick)
>Assuming you have AR managing Exchange already, I believe you can set the VA edsaEstablishGroupEmail to TRUE for mail enabling the groups.

That forces to respect EX side rules:
>AR VA flag for following Exchange policy. Has this not always been there? This is supposed to force AR to observe the Exchange org's rules.

and makes sense and great:
>Exchange doesn't seem to like two objects in AD to have the same PrimarySMTP address :-)

Support. Is it documented anywhere in AR manuals, SDK to use edsa VAs for the activity? if yes, then consultant passes all responsibility on AR engine, makes solution design clean, which is a right way.