> It seems that the VBS script only reads the OU that it is pointed to
> and does not go down the AD tree into sub-OUs. Is this correct?
Yes. However, there's a way to manipulate the command-line options to
encapsulate exchange2aliases within a batch file that loops through
the OUs and calls e2a for each iteration. Here's an example using MS'
built-in LDIFDE LDAP client:
ldifde -f ou_list.ldf -s 192.168.1.1 -r "(objectClass=OrganizationalUnit)" -p
subtree -l dn -b <administrator username> <NT/2000 domain> <password>
for /f "skip=2 tokens=1*" %%i in ('find "dn" ou_list.ldf') do cscript
exchange2aliases.vbs mail.broadleaf.local LDAP://%%j broadleaf.local
exchange.broadleaf.local
In case that isn't clear, the first part does deep recursion for all
OUs in a domain and dumps the the list to a file. The second part
scans the file, extracts just the OU name from a bit of other junk
that LDIFDE throws in, and runs exchange2aliases against each OU.
You could also manipulate lots of other stuff in the loop, like
changing the name of the IMail domain each time in concert with the OU
(if you're hosting multiple exclusive subdomains that are linked to
each OU, for example).
> Am I correct in assuming that if an e-mail comes in during the
> operation of the script and if the e-mail address in question is not
> there at the time IMail will reject the message?
Well, there is always a possibility.
> The way to mitigate this problem is to run the script at off-peak
> times but the possibility will always exist. Is there any way around
> this at present?
For one, the possibility won't exist if you stop the IMail SMTPD
service first.
You could also run ex2a with the -nc switch every night except, for
example, the last Friday of the month. This way, you'll keep deleted
users around longer in the Registry (which means that a hop-zero
bounce would be generated for those users only, rather than a
rejection at the envelope) -- but you couldn't have issues with a
partial Registry state except for that one night. And if you stop the
service that night, you eliminate the inconsistency worry altogether.
Anyway, there's no built-in way to stop this from happening. The
additional CPU and complexity of true reconciliation (only deleting a
Registry key if it is marked for deletion in an interim file) isn't in
the development plan.
> I suppose I could import the aliases to a fake domain in registry
> and then use some tool to copy/move the registry entries from the
> fake domain to the correct domain after the script is done.
I wouldn't bother with this if I were you.
> Another enhancement that I would like to suggest is that the script
> writes the registry entries to a file instead of directly to the
> directory so that I could gather the information and then very
> quickly import it into the registry. Also if it was written to a
> file then you could send the file back to the client so that they
> could validate the list of e-mail addresses.
Well. . . maybe in the fuure. But why would you want to validate the
addresses like that? It's not like the users don't exist in AD, since
ex2a queries AD directly; you can't have a "false positive" for the
existence of an e-mail address in AD.
It seems like you want the list for some other purpose, like
accounting/billing. You could get the address list via other methods
-- there are tools to just get that info. Also note that if you're
charging per-human-user, you have to eliminate user aliases, and ex2a
does not discriminate between the two.
--Sandy
------------------------------------
Sanford Whiteman, Chief Technologist
Broadleaf Systems, a division of
Cypress Integrated Systems, Inc.
e-mail: [EMAIL PROTECTED]
SpamAssassin plugs into Declude!
http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/
Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases!
http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/
http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/
---
[This E-mail was scanned for viruses by Declude EVA www.declude.com]
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
