is there any way to create and configure dynamic groups via powershell script? I don't see any cmdlets in the management shell that address dynamic groups.
(not sure) there might be ARS cmdlet QAD-GroupsXXX designated to dynamic groups.
hint: The group becomes dynamic when certain AD.group.attribute (do not remember exact name) is populated properly. XML format. It contains: ARS version, ARS server, scope, ldap query.
Regardless, I strongly recommend to use SDK documented method to dynamic-enable AD groups in order to have supported and less risky AD management workflow.
I already tried this - I'd worked out that teh attributes were and you cannot update them, I even spent time reverse engineering the attributes so I can work out what the rules are. I had to do this before I tried to update the attributes directly. The SDK only has vbscript examples :-( .
I've since come across a post that converts the vbscript example to Powershell and I can confirm this works:
where $newGroup is the object create when creating the new group and
$qbdls is an object that holds the searchbase and ldapquery to use
$objGroup = [ADSI] "EDMS://<ARSServerName>/$($newGroup.DN)"
# Return a reference to membership rule collection for this group
$objRuleCollection = $objGroup.MembershipRuleCollection
# Create a new 'Include by Query' rule
$rule1 = New-Object -ComObject "EDSIManagedUnitCondition"
$rule1.Base = "EDMS://$($qbdls.msexchdynamicdlbasedn)"
$rule1.Filter = $($qbdls.msexchdynamicdlfilter)
$rule1.Type=1 # 'Include by Query'
# Add a newly created rule to the rule collection
$objRuleCollection.Add($rule1)
$objGroup.SetInfo()
raw [ADSI] coding in PS1 instead of VBS. makes sense. good point.
Concern. The custom code developed ad-hoc will not be supported by support. Do you want to take a risk to have Dynamic Groups (!) management in your environment and not being supported?
This is a one off task and if they can tell which groups were created using a script and which were done manually then clearly I've not done it correctly. I'm having more trouble getting ARS to configure the mail addresses than getting the dynamic rules done. I thought new-qadgroup with the -mail switch would create a mail enabled group but it looks like it doesn't so I'm going to be loading the exchange commandlets to mail enable the groups. Just need the messaging team to give me the rights to do it now I can't use the -proxy switch. Add-QADProxyAddresses adds addresses even though the group is not mail enabled which is weird and there is no -proxy switch on that command which is stranger although perhaps I only need rights to the user object.
Assuming you have AR managing Exchange already, I believe you can set the VA edsaEstablishGroupEmail to TRUE for mail enabling the groups. There is a related flag edsva-MsExch-ApplyEmailAddressPolicy as well.
NIce find - I'll test this later and confirm if it works. My last attempt seems to show the Quest tools are a bit buggy when managing the Exchange attributes as it corrupted the email configuration completely.
I'd previously found about a year or so ago that Quest does not always follow the exchange rules and can in fact create invalid configurations by adding duplicate SMTP addresses and I got them to build in new functionality to allow me to break the link between the mail attribute and the PrimarySMTP address in a similar way to ADU&C has no link. What I found was that if you set the mail attribute to a value the PrimarySMTP address is updated too but they don't check if the email address you type in the mail attribute ( on the general tab ) is already in the directory. If you try to do the same on the email addresses tab then it won't let you add the duplicate proxyAddress. Strangely enough Exchange doesn't seem to like two objects in AD to have the same PrimarySMTP address :-)
Want to comment on some of your thoughts above for the benefit of the community...
[LA] My last attempt seems to show the Quest tools are a bit buggy when managing the Exchange attributes as it corrupted the email configuration completely.
[JS] Is it buggy or does it just do exactly what you told it to do? :) i.e. no safety net
[LA] I'd previously found about a year or so ago that Quest does not always follow the exchange rules and can in fact create invalid configurations by adding duplicate SMTP addresses and I got them to build in new functionality to allow me to break the link between the mail attribute and the PrimarySMTP address in a similar way to ADU&C has no link.
[JS] Well, I mentioned to you the 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.
[LA] What I found was that if you set the mail attribute to a value the PrimarySMTP address is updated too...
[JS] Really? This is bad because ADUC doesn't work like that...and isn't supposed to. That may be one of the default AR policies at play...I agree, not a good design.
[LA] ...but they don't check if the email address you type in the mail attribute ( on the general tab ) is already in the directory.
[JS] Well, no. It makes sense though because 'mail' is not authoritative for the e-mail address. And indeed scary as it sounds, I have seen customers put other e-mail style values in here that have nothing to do with e-mail.
[LA] If you try to do the same on the email addresses tab then it won't let you add the duplicate proxyAddress. Strangely enough Exchange doesn't seem to like two objects in AD to have the same PrimarySMTP address :-)
[JS] And this is how I would expect it to work as the e-mail addresses tab is representing the Exchange side of things which is supposed to be authoritative for all things mail.
