Category Archives: Exchange

Gotcha when adding Exchange transport rule disclaimers

Recently I was involved in a project to test outgoing e-mail disclaimers for only a specific group of users in our company.  Normally this would be a no-brainer using the standard features in Exchange transport rules to add a disclaimer using specific criteria.  However, while testing the disclaimers with a colleague, he observed that his tests worked fine when sent from a mailbox on Exchange 2007, but failed to work at all when coming from a mailbox on Exchange 2010.

So I began troubleshooting this issue and trying to find the cause of the problem.  In our company we actually have 3 generations of Microsoft Exchange running in a co-existence scenario (2003, 2007 and 2010 – with 2013 coming soon).  I tried everything I could think of to get the transport rule disclaimer to work, testing it on my own mailbox which is hosted on an Exchange 2010 server.  Sure enough the disclaimers did not work for my account.

I poured over KB articles and forum posts scouring the internet for any tips that might at least point me in the direction.  After several hours of searching I stumbled upon a forum post indicating that I should check the “remote domains” properties in the Exchange shell.  So I ran the command “get-remotedomains | FL” and sure enough the “isInternal” value was set to “true”.  Given that our transport rule disclaimers were conditional upon being sent to recipients who were “external” to our Exchange organization – of course none of the rules would work.

In order to resolve the issue, I ran the following command: “get-remotedomain | set-remotedomain -isinternal $false

This allowed Exchange 2010 hub transport servers to recognize all email recipient domains not configured in our Exchange organization as “external”.  A second round of testing revealed that this change did in fact resolve the issue and the transport rule disclaimers worked perfectly for everyone, both Exchange 2007 and 2010 mailboxes.

I am amused and slightly annoyed that the vast majority of forum posts and KB articles I found about how to use Exchange transport rules to send outbound disclaimers has no mention of this possible “gotcha”.  I’m sure there are limited circumstances that would result in this issue which is probably why it was not mentioned in the articles I was reading, but I offer this as help to those who may face a similar situation.

Confusing behavior in Exchange 2007/2010 when changing Hub Transport DNS configuration

I recently ran into a configuration issue in Exchange 2007/2010 that left me scratching my head in bewilderment.  After noticing some DNS resolution issues between several hub transport servers I began looking at individually and manually configuring DNS resolution settings on specific Exchange servers.  In ESM I went to “Server Configuration > Hub Transport” and viewed the properties of each server.  On the “Internal DNS lookups” and “External DNS lookups” tabs you get the option to choose either the DNS configuration from a specific network adapter or manually enter the DNS servers to use.

To save time, I began using the drop down selection of specific network adapters to grab the DNS servers I wanted.  However, there is an important “gotcha” here that is not indicated in the GUI or anywhere else that I’ve seen.  Basically what is happening is that when you use the drop down NIC selections to grab DNS, what you are doing is querying the NICs of the server on which you are running ESM.  So what happened in my case is that incorrect DNS servers were being assigned to remote Exchange servers because I assumed that the NICs being listed in the drop down were the NICs physically installed on the remote server for which I was viewing the properties.  Big mistake!

I started noticing events in the logs complaining about inability to resolve DNS hosts.  Once I started investigating this it dawned on me that the names of the NICs in the drop down listing never changed as I viewed the properties of different servers.  It just happened that the NIC I chose did not have any DNS servers configured, so I was basically configuring those specific Exchange servers with no DNS at all on the hub transport DNS resolution configuration.

To resolve the issue, I manually specified the DNS servers to use for each specific Exchange server.  That completely resolved the problem and got mail flowing again.

Just kind of curious why Microsoft would allow you to manage remote servers from one location/instance of ESM but only show you the NICs on the local server when configuring remote server hub transport properties.

De-evolving technologically

A lot has happened since I last posted, but I thought it would be good to post a quick update on the changes I’ve made technologically over the last few months.

The first major change is the decommissioning of my personal Exchange mail system.  My home server setup was getting far too complex and expensive to maintain so it was decided to do some downsizing and basically get rid of a bunch of servers.  At the time I began to remove servers, there was 6 being used full time.  It got to a point where I had built a powerful white-box server on which to run VMWare ESXi 5 which allowed me to virtualize all of my servers.  There were 2 for AD/DNS/DHCP and 2 for Exchange 2010 in a DAG and 1 for simple/general tasks like backups and game servers.

To be honest, my wife and I got quite accustomed to having enterprise level features in our home e-mail solution.  As someone with about 12 years of Exchange experience I had it setup right which included custom domain names, SSL certificate, networking to support ActiveSync for our iPhones, etc.  I had wanted to simplify things for quite a while, but never could find just the right solution to handle our e-mail and calendaring in a way that would remain highly functional and not be difficult to migrate to.  Then along came a new service by Microsoft called  Long story short, is everything we needed to get rid of Exchange and simplify the home setup.

Our email, calendars, contacts, etc – were all easily migrated to  Of course I had to dump about 8GB of archived messages to PST files out of Exchange, but thats a normal part of the process.  For the time being, we’re still using Microsoft Outlook to grab old messages, but for all new messaging features we’re going with Windows Live Mail.  It integrates nicely with and gives us a very nice user experience with pretty much all of the features that we were accustomed to while using Exchange.

Unfortunately, the networking side of things hasn’t transitioned quite so easily.  When we had all of these servers running they were responsible for most of our networking services, like DNS/DHCP.  Transitioning to router based network services was a bit of a challenge.  I ended up buying an Asus RT-N66U dual band 802.11N Wi-Fi router.  The Verizon FIOS router is forwarding all traffic to the Asus router (DMZ).  In the Asus router I’m doing all my port forwarding rather than having the Verizon router handle of that.  Mainly because the ASUS router won’t allow many of its advanced features if its configured as a mere AP, it must be in router mode for the bells and whistles.

An unfortunate side-effect of this transition is that all of our Apple Devices appear to be rather slow on Wi-Fi using the new home network setup.  I’ve run lots of diagnostics and tried many tweaks but nothing I’ve done so far has restored pre-transition device speed for the iDevices.  Strangely enough my laptop works fairly well on both the 2.4GHz and 5GHz Wi-Fi Networks.  I suspect there is some advanced tweaking that could be done to improve the iDevice performance over Wi-Fi, but so far I haven’t figured it out.

At this point, my office has one nice PC in it, a PC that is quiet and easy to maintain. The big server is now going to go up for sale, hopefully on Craigslist.  After adding everything up, it seems I have approximately $1,200 worth of server/parts available for sale.  This was a great machine, dual quad core Opteron 2.2GHz CPUs, 32GB DDR2 memory, 6 SATA HDD for over 5 TB of disk space, etc.  This machine was perfect for virtualizing servers, the only downside is the noise and heat.

To sum up, I’m no longer running a bunch of servers at home.  No more Exchange for home messaging, no more noise, no more extra heat in the office, its all gone.  And its interesting how quickly we grew accustomed to the noise in the office and how much we enjoy the quiet now that its gone.

In addition to the servers being removed, I also finally got us off the Ooma VOIP service.  Someone purchased the Ooma box from me via craigslist and took it off my hands.  Since we’ve bundled phone services with Verizon FIOS there was simply no further need for an additional home phone service. is handling our messaging needs very nicely.  The web interface is easy to use and very clean.  It supports Active Sync via the Hotmail connector in the Apple Mail client, which is very nice.  The only things we really miss are server based Distribution lists and shared calendars.  However, none of that was a deal-breaker for us.

As a result of the downsizing, it looks like we will be saving approximately $600 a year in services and fees from all of the various resources I needed in order to run such a system at home.  That includes Microsoft licensing and domain names, SSL, etc.  Needless to say this transition is going to be a cost saver with only a few minor networking kinks to work out.

Drive failure in my personal Exchange 2010 server

A few months ago I upgraded my home Exchange mail system from Exchange 2007 to Exchange 2010.  During this process I added a secondary server that was identical to the main server.  By having two Exchange 2010 servers I was able to utilize the DAG feature that is new in this version of Exchange. 

All that to say – yesterday my main Exchange server disk drive failed.  I got home from work and shutdown the server, removed the hard drive and tried to run some tests.  All I got was clicking, it won’t even see the partition table.  Fortunately, since I was running Exchange 2010 with a DAG for redundancy, I was able to quickly activate the database copies on the secondary server thereby eliminating any downtime or data loss of my Exchange system.  Currently, the secondary server is actively hosting my databases.  My mobile phone still works through ActiveSync, OWA works, incoming and outgoing mail also, no problems! 

I’ve purchased a replacement drive which should be here in a day or two.  The downside is the drive that failed has failed to a degree where recovering the drive is highly unlikely.  Since I don’t have RAID on any of my servers (due to cost) I will end up having to rebuild this server.  My next steps will include reinstalling the Operating system and Exchange 2010.  I plan on using a recovery mode install of Exchange 2010 which should restore all my Exchange settings and configuration leaving very little left to do but tweak a few things and make sure my DAG is re-created.  My only other option is to manually remove all traces of the failed server from Active Directory and then re-install Exchange in normal mode.  This would be a little more work so I’m hoping the recovery mode install will work properly. 


Migrating to Exchange 2010

Last week, I took on the task of migrating my personal home mail system from Exchange 2007 to Exchange 2010.  As usual with Microsoft Exchange, there is no direct upgrade.  A migration is from one system to the other is the main method of accomplishing this task. 

This project was accelerated to the top of my todo list after taking a week long training course at Tech Sherpas on Exchange 2010.  The new high availability features and the added resiliancy of Exchange 2010 sold me on the new flavor of Exchange very early on.  I’m going to go through some of the things I experienced and learned during my migration.  I’ll be going through another migration soon and will append this post with any added information I disciver during a second g0-round. 

It all starts with Active Directory and DNS.  Planning your Active Directory and DNS namespace is critical to having a healthy and resiliant Exchange mail system.  I made a critical error a few years ago when setting up Active Directory in my home office.  I had chosen the AD domain name “” to use internally, since I was not anticipating using any products that would create a conflict when using a public domain name internally.  The problem I had was with SSL certificates.  I wanted to get an SSL certificate that used SANs so that I could access OWA and ActiveSync internally and externally without getting a certificate prompt.  The issues started when I tried to generate a certificate using the domain name, since its a public domain, anytime I tried to add a SAN using that domain, the request would fail.  Since is a public domain, whowever owns it would have received the requests to create a certificate on that domain.  I called the SSL certificate provider I was using and confirmed with them that there is no way around this, I would have to change my internal domain name or not use it at all in my certificate.  So that is where my post about renaming an AD domain comes in.   Once I renamed my AD domain to something clearly internal only, I was able to generate my SSL certificate with all the SANs that I needed. 

Now regarding the actual migration of Exchange 2010, it was a bit tricky.  I ran into problems exporting my mailboxes from Exchange 2007.  I had to install the Exchange management tools on another server and install Outlook and all the prerequisites required to make the export work, which was a huge pain.  I’m seriously hoping that Microsoft one day makes mailbox exports a little easier and require less legwork to make it happen.  I finally got my mailboxes exported and jotted down most of my critical Exchange settings. 

Normally you would just install Exchange 2010 on a new server and migrate your mailboxes and other content over to the new server.  You can then shutdown the old server and you are done.  However, I had the domain rename issue to worry about which cannot be done if Exchange exists in your AD domain.  By removing Exchange completely, I was not doing a migration in a strict sense of the word, but instead a new installation and ended up importing mailboxes and manually restoring settings. 

I installed Exchange 2010 with no problems on my first server.  I then tried to import my mailboxes and ran into problems.  Turns out there is a known issue with Exchange 2010 and importing mailboxes on a single server.  So I setup a second Exchange 2010 temporarily and was then able to try again, this time I found that I could not export the mailboxes because the mailbox server absolutely has to have Outlook 2010 installed on it.  This is completely different from previous versions of Exchange where we are warned not to install Outlook on the Exchange server.  I finally got all the requirements in place and was able to import my mailboxes.  So far so good. 

I had some difficulty getting my Outbound SMTP connector re-configured, but I think that issue was only due to me fat fingering the password or authentication methods.  The next step was to try to take advantage of Enterprise features like DAGs for high availability.  The first issue I ran into here was that Exchange 2010 requires a host operating system of Server 2008 Enterprise edition in order for this to work (since clustering is used in the background).  My second server was only Server 2008 Standard edition, so I had to reload the server using Enterprise edition in order to proceed with my setup.  I finally had both server running the right operating system, same version of Exchange 2010 and ready to go.  Oh, one little caviat is that if you install any of the update rollups for Exchange 2010, you will run into issues when trying to uninstall Exchange 2010.  You get an error saying that a previous version of the product is already installed and it recommends removing the previous version before installing this one.  To get around this, just remove the update rollup and reboot.  Then re-appy the update rollup and then try the uninstall again.  That worekd for me and I was able to do my uninstalls with no further problems, although this took me a few hours to figure out. 

End result of hours of work for most of the day on Saturday was two fully functional Exchange 2010 servers with working mailboxes, incoming and outgoing mail and partially functional SSL certificate.  The Certificate issues were resolved a day or two later once I finally got my certificate straightened out with the provider, I had to re-key it a few times and wait for the e-mail confirmation. 

Now to work on high availability.  I created a Database Availability Group (DAG for short) and ran into some small issues with permissions.  I wanted to use my AD domain controller as my “witness” for the DAG, but I would get errors when trying to create the DAG which I discovered were actually permission errors.  If your witness server is not another Exchange server, you must add the “Exchange Trusted Subsystem” Security group to the local Administrators group of the server you are going to use.  Since in my case this is a domain controller on a private home office system, I just added the group to the Administrators group in AD, which accomplished what I needed to get this to work.  Once that was taken care of, I was able to create a DAG successfully.

Once the DAG is created, I then proceeded to add server members to the DAG, which took longer than I expected, but worked absolutely perfectly.  Once that step is done, you can proceed to add copies of mailbox databases to the DAG.  I added copies of my two databases to the DAG and made one server the first preferred server and made the second server the failover by assigning a preference value of “2”. 

I did some basic tests of the DAG failover and found that it worked perfectly.  I could switch back and forth between servers and it only took a few seconds at most.  During my testing, OWA clients would momentarily get a message saying an item was unavailable if they just happen to be opening a message during the first few seconds after switching servers.  Outlook clients would also only have a momentary issue if a user happened to be opening a message in online mode when the transition of servers is taking place.  For all intents and purposes the switchover of mailbox servers is transparent to the users, which is awesome! 

Another great feature of Exchange 2010 is that you can now move mailboxes between mailbox servers while the users are connected to their mailboxes.  The new “move request” feature allows the move to take place with the mailbox in use and any changes to the mailbox after the move is complete are written to the database to bring it current on the new mailbox server.  Users that are connected via Outlook will get a message saying that changes have been made that require Outlook to be restarted.  Once you restart Outlook, you are connected to your new mailbox server automatically (assuming the old server is still online to allow redirection to occur). 

How about backups?  This is one of my favorite things about the new Exchange 2010 DAGs.  Because you can now have super easy high availability in Exchange 2010, you get the added perk of making backups more efficient.  How?  Simple, backup your secondary DAG member databases.  Assuming you have at least one server in the DAG with a real time copy of the database in question.  By backing up the secondary copy, you reduce mailbox server load, by not running backups on a server users are connecting to.  Because its a real copy of the database, you can do brick level restores and anything else you would normally do in your backup strategy. 

To restore content in Exchange 2010, rely on your deleted items retention period for most of the common short range restore requests.  For anthing greater than that, you can restore a backup of a mailbox or an entire database to an Exchange recovery database.  Then use Exchange management shell cmdlets to recover specific information or the entire mailbox to the production database or mailbox. 

A few other perks that aren’t so loudly advertised about Exchange 2010:}
   1. OWA is now supported fully in other browsers, yes it works in firefox without having major rendering issues or having a requirement to use the “light” version.
   2 OWA now supports conversation views of message threads
   3. Exchange control panel lets administrators and regular users manage many aspects of their DL membership and account info right from their web brwoser.  This includes their mobile device management, contact info, ability to create new DLs, etc.
   4. There is better role based management of feature/security access in Exchange 2010.  You can define custom roles or use the default roles provided by Microsoft.  This is good for large companies who want to separate roles between admins. 
   5. Mailtips are cool!  You can create custom mailtips to be displayed at all times, in addition to the intelligent mailtips displayed by the OOO or calendar conflicts.  Mail Tips are informational messages displayed to the sender of new messages or calendar requests when using Outlook 2010 or OWA.  For example, if you send a user a meeting request, if the user isn’t available due to a calendar conflict, Mail Tips will let you know before you ever send your message and will suggest alternate dates for your meeting based on the user’s availability.  In addition, if a user has the OOO turned on, if you try to send a message to that user, you will get a Mail Tip telling you the user is out of the office and you will get a preview of the first fiew lines of the OOO message the user customized in his auto-reply. 
   6. If you will be using Exchange 2010 high availibility to handle your backups using DAGs and multiple database copies setup for a log reply lag, you can go ahead and set your loging to “circular”.  However, if you will be using another product to backup Exchange, such as Data Protection Manager or Backup Exec, then you will want to keep your logging setup as normal, so that your backups will clear committed logs.  Otherwise you will get warnings in Data Protection Manager specifically, that a synchronization isn’t possible because you are using circular logging and only full copies of the database can be used. 

There is so much more I could mention, but those are probably some of the best parts of Exchange 2010.  For more information I recommend giving the tiral version a try, or download a virtual Hard Drive and see for yourself all of the major improvements in Exchange 2010.  Some of the documentation isn’t very detailed yet, I had a hard time finding step by step instructions, so it seems this is one of those times when a good lab setup for testing is a great idea to get familiar with the caviats of how things work and what is required to get them configured.

My first AD domain rename

I recently had the pleasure of getting to perform my very first Active Directory domain rename.  This situation was the result of some bad planning on my part a few years ago when I first setup Active Directory in my home office, but I’ll talk about that in a separate thread that deals with Exchange 2010.

To do the rename, I was expecting to see the “Rename domain” option in ADUC, but as it turns out its all command line.  So after a few commands of the rendom tool, I was able to rename my AD domain.  I first had to remove Exchange completely, then I was able to perform the rename.   It wasn’t that bad and went rather well.  I did run into a few bumps, such as my DNS server needing a manual re-config, and the connected client machines (desktop and laptop) did not automatically update their DNS suffix.

I wouldn’t recommend doing this unless absolutely necessary, and I very nearly did just start over from scratch, but I wanted to press on and see if I could get everything to work on a renamed domain.  To my delight, it worked and I’ve even got Exchange 2010 running now.  The only thing I would recommend is to re-install Exchange on a server with a different node name than what it had previously.  This caused me all sorts of little issues that I’ll deal with later in a separate post.

Change mailbox alias or re-create Exchange mailboxes results in NDR from bad Outlook recipient cache

In the past when renaming or re-creating mailboxes in Exchange I’ve had issues where the Outlook cached entry for the user no longer works when internal users send mail to the specified mailbox. This is because of our dual Exchange environment running mixed versions of Exchange. The original mailbox was created under Exchange 2003 and ultimately moved to Exchange 2007, but preserving the Exchange 2003 Mailbox reference for X500. When a mailbox is re-created or the alias is changed, it can break these cached entries in Outlook. Today, I discovered a way to work around this issue from this article.

In the future if I need to change alias (due to name change) or if there are problems resulting in a need to re-create the mailbox, the steps in the article can be used to avoid having mail delivery problems for the affected user.

• The listed steps will allow the cached Outlook entries to properly resolve the user mailbox. No user action is required to make this work.
• You can find the proper alias for the user in an NDR message or by going to the cached entry in outlook and viewing its properties. It will be a string in one of the values displayed on the properties. (Note, this only works before you make the changes above).
• The updated string for the Exchange 2007 environment is automatically added to re-created mailboxes in X400 form. The old pointers can be added using X500.
• This issue only affects mail sent from internal clients using the cached entry in Outlook, all SMTP mail flow and external mail will continue to flow to the user uninterrupted regardless of this issue.

Exchange 2003/2007, IIS 6 Metabase and SMTP domains

   Recently I ran into a very strange issue with Exchange 2003, IIS 6 and SMTP domains.  The environment is a mixed Exchange 2003/2007 site with about 10 public SMTP domain names for which this Exchange org is responsible for.  Since the beginning of my time as the Administrator for this system the recipient policy settings have been the same.  All the SMTP domains are listed in the recipient policy but some are unchecked.  For years this has been the case and we’ve never had a problem.  But something must have happened recently, because the last few days have been busy for me trying to figure out what was causing a mail delivery issue that resulted in all incoming mail for several of the legitimate public SMTP domains to bounce back to the sender.

   After some research and manual testing to try to identify what was causing the problem, I found a strange thing.  In the IIS 6 metabase on one of the Exchange 2003 servers, the public SMTP domains were missing from the “domains” key under LMSMTPSVC1DOMAIN.  Two of our domains were listed but all the rest were missing.  If the domains are not listed in the IIS metabase for SMTP, the server will reject mail sent to those domains because it doesn’t realize that its responsible for receiving mail for them.  So I decided to do a test, I opened up the recipient policy and put a check next to all public SMTP domains and waited a minute before refreshing the IIS metabase information.  When I checked again, I found all the public SMTP domains were correctly listed in the IIS metabase now. 

   Earlier in the day I was trying to send test messages via telnet through SMTP.  When I would try to send a test message to a user on one of the affected domains I would get the error “unable to relay for”.  After refreshing the IIS 6 metabase, my telnet test messages were being accepted successfully and I confirmed that the user was receiving them.  Again, the recipient policies have been the same since the beginning of the AD in this site.  I have no idea why all of a sudden we would see incoming mail problems.  I can only speculate what might have happened, perhaps a quirk due to an unexpected DC shutdown, or maybe its some weird fluke with IIS 6 and some other third party apps that have SMTP event hooks that caused it.  I really have no idea and I don’t have a screenshot of the IIS 6 metabase config from before the time when we started to have problems. 

   What fixed the problem was to make sure all the public SMTP domains appeared in the IIS 6 metabase.  After that was taken care of, mail delivery issues were fixed and I was able to verify this using manual telnet test messages.  So I know what the problem was and I know what fixed it, I just don’t know what actually caused the problem in the first place. 

   If you don’t have a metabase explorer, you can use the one included in the IIS 6 resource kit, which is available as a download from Microsoft.

Batch and Automate Distribution List membership

***Please read update in Red at the bottom of this post***

Immagine you are in the I.T. Department at a larger company.  Now immagine that your users get a lot of e-mail, seriously, thousands a day – mostly because they are on distribution lists for the company which receive a lot of mail.  Now picture these users traveling internationally and wanting to save on roaming data charges by cutting down on the volume of e-mail they receive on their mobile phones, or simply want to go on vacation and not have to deal with the burden of managing their e-mail while they are out of the office.  On top of all this (by this time you may really working your immagination) the users want you to take them off of a huge number of lists at weird times of the day such as 10pm.  In addition they want to be re-added at 5am the following week.

How do you handle the above scenario?  What would you do?  Normally the users I deal with may just accept that they have to stick with normal business hours for list changes such as I described above.  Or perhaps they will rely on international I.T. Support to do it for them due to the convenience of time zone differences.

What if there were a better way to deal with this situation?  Would you be interested?  What if there was a way to batch and automate the addition or removal of Distribution Lists on a user’s account?

I found myself in exactly the same situation I described above.  I spent some time researching my options and trying to find a good solution; something that would let me create batch files which could be setup as a scheduled task in widnows.  Something that could add and remove DLs from a user’s profile at any time of the day or night without me having to pyhsically make the change myself.  To my surprise, I couldn’t find anything out there that would do the job.  Thats when I decided to head over to and ask for some help creating an application or script that would do what I needed.

With gracious work by member chris128, a new application was created that completely takes care of the above scenarios.  Chris created an application called DLManager in VB.NET, and I performed real world testing and evaluation of the program.  This is a very useful application that goes even beyond Distribution List management into the realm of security groups as well.  Which means you could batch, automate and schedule Active Directory security group membership changes as well.

Application Information:

* Compiled VB.NET executable meant to be called from the command line
* Requires the .NET framework 2.0 or higher in order to function
* Can be run in a DOS batch file
* Can be scheduled via batch script or other automation tool (see
* Very small footprint at less than 30kb in size
* .ini config file to hangle AD domain configuration information

Command line syntax: dlmanage.exe [add/remove] [target AD username]  [DLNAME] (OPTIONAL): adminusername adminpassword

Example for admin user: dlmanage remove jdoe “Information Technology”

Example for non-admin user: dlmanage remove jdoe “Information Technology Administrator AdminPasswordHere

NOTE: Quotes are only needed for DL or security groups that have spaces in the name.

(this download is free software, and full credit goes to the author, see author’s site for more details)

************* IMPORTANT***************
Chris has released an updated version that is easier to use, has new featuers like better error handling, primary group awareness and no more config.ini file.  I’ve updated the download link to give you the newer version of the program.  For complete details, please see Chris’s Site at

Updated program syntax example: DLMAnage Add username group1,group2,group3